Celestin Apprentice 5/Apprentice-Release5.iso/Information/CSMP Digest/volume 3/csmp-digest-v3-128

Text File | 1995-12-19 | 125.5 KB | 3,554 lines | [TEXT/R*ch]

C.S.M.P. Digest             Tue, 19 Dec 95       Volume 3 : Issue 128

Today's Topics:

        Apple Multiple Scan Color Modes
        Best Installer package for freeware software
        Detecting color video
        Doubles Vs BlockMove
        Hiding the menu bar
        MoveControl and popup menus
        Non-resource custom PowerPC LDEF
        OpenDoc lingo
        Palettes and QuickTime
        Passing a member function to DeviceLoop?
        Question: Do you need to lock a Sound Handle before SndPlay
        What's in a stack frame?
        [Q] OpenTransport Introduction?
        [Q] Using Update Events



The Comp.Sys.Mac.Programmer Digest is moderated by Francois Pottier
([e-mail]).

The digest is a collection of article threads from the internet
newsgroups comp.sys.mac.programmer.help, csmp.tools, csmp.misc and
csmp.games. It is designed for people who read news semi-regularly and
want an archive of the discussions.  If you don't know what a
newsgroup is, you probably don't have access to it. Ask your systems
administrator(s) for details. If you don't have access to news, you
may still be able to post messages to the group by using a mail server
like anon.penet.fi (mail [e-mail] for more information).

Each issue of the digest contains one or more sets of articles (called
threads), with each set corresponding to a 'discussion' of a particular
subject.  The articles are not edited; all articles included in this digest
are in their original posted form (as received by our news server at
nef.ens.fr).  Article threads are not added to the digest until the last
article added to the thread is at least two weeks old (this is to ensure that
the thread is dead before adding it to the digest).  Article threads that
consist of only one message are generally not included in the digest.

The digest is officially distributed by two means, by email and ftp.

If you want to receive the digest by mail, send email to [e-mail]
with no subject and one of the following commands as body:
    help                                Sends you a summary of commands
    subscribe csmp-digest Your Name     Adds you to the mailing list
    signoff csmp-digest                 Removes you from the list
Once you have subscribed, you will automatically receive each new
issue as it is created.

The official ftp info is //ftp.dartmouth.edu/pub/csmp-digest.
Questions related to the ftp site should be directed to
[e-mail].

-------------------------------------------------------

>From [e-mail] (Matthew Channon)
Subject: Apple Multiple Scan Color Modes
Date: 27 Nov 1995 20:15:42 GMT
Organization: New Mexico Tech

Changing depths on Apple's newer monitors is a necessity.

Sometimes you want 1024x768 at 8-bit for more screen real estate,
and other times you want 640x480 at 24-bit for good color editing.

System 7's monitors control panels makes this possible, but it's a truly
cumbersome process.

First you have to open monitors, click options, click on the depth you want,
click okay, and close monitors.  Although it's not that difficult, it can
be quite time-consuming.

I'm trying to write an extension, control panel, or FKEY that takes care of
this process at the mere touch of a button, much like DepthCharge or
Switcheroo does with color depths.
Apple has not as of yet (at least to my knowledge) documented how this
process takes place or can be called.

Does anyone out there have an idea how this could be accomplished?
(A snippet of applicable code from the monitors control panel would be
appreciated as my new mac has no <expletive omitted> interrupt key.

Thanks,

Matt Channon
Materials Engineering Student (Mac enthusiast)
New Mexico Institute of Mining and Technology

+++++++++++++++++++++++++++

>From Matt Slot <[e-mail]>
Date: 28 Nov 1995 16:18:34 GMT
Organization: University of Michigan

Matthew Channon, [e-mail] writes:
 > I'm trying to write an extension, control panel, or FKEY that takes care of
 > this process at the mere touch of a button, much like DepthCharge or
 > Switcheroo does with color depths.

Check out the "Monitor's FKEY", which is available at Sumex
(I don't have the path, its an odd one) and from my Homepage
<http://www.sils.umich.edu/~fprefect/>

It does what you are looking for, and I am working on an
improved version that handles multiple monitors and actually
cleans up the desktop icons after a switch.


 > Apple has not as of yet (at least to my knowledge) documented how this
 > process takes place or can be called.

If you still want to find out about Monitor Modes (and it *is*
a nasty subject), check out the Slot Manager, (Nubus) Cards and
Drivers, PCI Cards and Drivers, *and* the recent Display Manager
documents. My code is pretty nasty, so I don't think I will post
it to the public.

---------------------------

>From [e-mail] (Julian Fletcher)
Subject: Best Installer package for freeware software
Date: Wed, 29 Nov 1995 16:52:12 +0000
Organization: University Of Manchester, UK

Most commercial installer packages, e.g. 'smaller installer' are relatively
expensive and appear to make no concessions for freeware software.
I'm looking for an installer package that can support files strewn over
multiple disks and which handle the installation process in a user
friendly way. The projects that am working on are freeware in nature
so I am not keen on spending vast amounts of money on licensing
fees.

Any suggestions anyone ?

(Replies via email appreciated)

Julian
[e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (Reevan McKay)
Date: Fri, 1 Dec 1995 18:49:55 GMT
Organization: Carleton University

Julian Fletcher ([e-mail]) wrote:
> Most commercial installer packages, e.g. 'smaller installer' are relatively
> expensive and appear to make no concessions for freeware software.
> I'm looking for an installer package that can support files strewn over
> multiple disks and which handle the installation process in a user
> friendly way. The projects that am working on are freeware in nature
> so I am not keen on spending vast amounts of money on licensing
> fees.

How about CompactPro self-extracting, segmented archives?  It will
prompt the user to find each file when it needs it, and gets fairly decent
compression rates.  To register it costs $25 I think, but you can probably
even get away without registering it.  You can find it just about
anywhere, but I'm sure it's on info-mac in the utilities or compression
directories.

It isn't a true INSTALLER (i.e. it can't adjust the installation for a
particular system configuration) but it will allow you to get the large
files onto disks and onto the HD's of your users.

Stuffit doesn't seem to support .SEA segmented files for some reason.


- --------------------------------------------------------------------
Mikado
Second Year Architecture
Carleton University

"Jesus was an architect, previous to his career as a prophet."

Email address: [e-mail]
- --------------------------------------------------------------------

+++++++++++++++++++++++++++

>From [e-mail] (Steve Kiene)
Date: Fri, 01 Dec 1995 14:29:25 -0700
Organization: MindVision Software

In article <[e-mail]>,
[e-mail] (Julian Fletcher) wrote:

> Most commercial installer packages, e.g. 'smaller installer' are relatively
> expensive and appear to make no concessions for freeware software.
> I'm looking for an installer package that can support files strewn over
> multiple disks and which handle the installation process in a user
> friendly way. The projects that am working on are freeware in nature
> so I am not keen on spending vast amounts of money on licensing
> fees.

Developer VISE Lite from MindVision Software is _free_ to
shareware/freeware developers. Just send me e-mail for more info.

Steve Kiene
MindVision Software

+++++++++++++++++++++++++++

>From [e-mail] (bill coderre)
Date: Fri, 01 Dec 1995 16:15:00 -0800
Organization: GRAFIX::CODERRE

In article <[e-mail]>,
[e-mail] (Julian Fletcher) wrote:

| Most commercial installer packages, e.g. 'smaller installer' are relatively
| expensive and appear to make no concessions for freeware software.
| I'm looking for an installer package that can support files strewn over
| multiple disks and which handle the installation process in a user
| friendly way. The projects that am working on are freeware in nature
| so I am not keen on spending vast amounts of money on licensing
| fees.

If you are just installing a bunch of files into a folder, it's hard to
beat Stuffit Installer Maker or DeveloperVISE. Both offer cheap shareware
rates.

The Apple Installer is better for installing extensions, fonts, etc.

If you have Apple Installer questions, feel free to contact me, and I'll
try to answer them.

bill coderre
Apple Installer Guy

---------------------------

>From [e-mail] (IAmAndy)
Subject: Detecting color video
Date: 2 Dec 1995 20:19:53 -0500
Organization: America Online, Inc. (1-800-827-6364)

Subj: MAC System 7 or later, C Programming, Detecting Color

How do you detect if a computer supports color?  Is there a quick draw or
gestalt command?

I know how to detect if color quick draw is present, but I can't find a
test for if the display is in color or black and white mode.

SysEnvirons( curSysEnvVers, &theWorld ) ;
if( theWorld.hasColorQD == true )
        SupportsColorDraw = true ;

Any help or references would be appreciated.

Andy.

+++++++++++++++++++++++++++

>From Edward de Jong <[e-mail]>
Date: 3 Dec 1995 19:55:48 GMT
Organization: magic mouse productions

You can certainly determine what mode a particular device is in.  Now
most people forget that the Macintosh supports up to 5 simultaneous
monitors, each of which can have different capabilities and sizes.  I
selected the Mac to develop on for this very reason, as I am trying to
preserve my eyesight by typing and editing on the grayscale monitor, and
watching my color program execute on the other monitor.  Anyway, you can
search though the devicelist, and find screen devices, and for each
device interrogate that device as to its current mode, and what modes it
is capable of getting into.  My product, Flying Colors, looks for the
largest color monitor around to determine which monitor to run on.  You
can't move the menu bar over, but it is a great convenience on multiple
monitor systems if the programs are smart enough to detect this.



+++++++++++++++++++++++++++

>From [e-mail] (Kaos)
Date: 5 Dec 1995 04:27:42 GMT
Organization: The Network

In article <49qtvp$[e-mail]>, [e-mail] (IAmAndy)
wrote:

> Subj: MAC System 7 or later, C Programming, Detecting Color
>
> How do you detect if a computer supports color?  Is there a quick draw or
> gestalt command?
>
> I know how to detect if color quick draw is present, but I can't find a
> test for if the display is in color or black and white mode.
>
> SysEnvirons( curSysEnvVers, &theWorld ) ;
> if( theWorld.hasColorQD == true )
>       SupportsColorDraw = true ;
>
> Any help or references would be appreciated.
>
> Andy.


This snippet will get the current screendepth:
                GDHandle                tempGDH;
                short                   theDepth;
                tempGDH = GetGDevice();
                theDepth = (*(*tempGDH)->gdPMap)->pixelSize;

You can then call HasDepth to see if the monitor supports the colour depth
you require, if it supports it call SetDepth to change it. If you need the
code to do this , then:



short   someResult;             //result from depth change (if zero then it was done
okay)
short   hasMode;                //result from depth check (if non zero then it supports
this depth)
short   newdepth;               //the var. for the depth
short   whichflags;             //the var. for which bits are significant
short   newflags;               //the var. set to 1 colour or 0 for mono)
GDHandle        myGDevice;

        myGDevice=GetGDevice ();        //get the current screen
        whichflags=1;                           //set up to change the depth and colour mode only
        newflags=1;                                     //this version supports colour only! (except depth 1 of
course!)
        newdepth=32;                            //millions, use16 for thousands, 8 for 256 etc.
        hasMode = HasDepth(myGDevice,newdepth,whichflags,newflags); //check to see
if the device supports the selection
        if (hasMode)  { //if it supports the depth then do it
        someResult = SetDepth(myGDevice,newdepth,whichflags,newflags);  //Try and
set the depth, should always work as we've tested it with hasdepth!!


add your own error handling etc.

Hope that helps a little

Dave

Struggling developer trying (usually in vain) to  advance his programming
skills.
Code Warrior Gold addict and general bum!

"Just another lost sock in the tumble dryer of life"

---------------------------

>From [e-mail] (Erichsen)
Subject: Doubles Vs BlockMove
Date: 16 Nov 1995 02:22:08 GMT
Organization: Disorganized

I did some tests (modifying the code in MoveData app from Tricks of the
Mac Game Programming Gurus) between using doubles in a loop and BlockMove
in a loop and BlockMove still blew it away (200 ticks vs 146 ticks for
BlockMove) so why don't more people use BlockMove?

I compared BlockMove vs BlockMoveData and found no difference at all (both
146 ticks). Does BlockMove not flush the cache on a 6100?

One of the replies to my previous question of why people don't just use
BlockMove instead of a copying loop was that the data is not necessarily a
block but, all the examples of blitters I've seen just copy one contiguous
block of memory to another contiguous block of memory. Why couldn't
BlockMove be used?

+++++++++++++++++++++++++++

>From [e-mail] (Cameron Esfahani)
Date: Mon, 20 Nov 1995 11:55:46 -0800
Organization: Apple Computer, Inc.

BlockMove/BlockMoveData on the first generation PPC are exactly the same
function.  The reason that BlockMoveData was created in the first place
was you could tell the system you were not moving code around and to not
flush the instructino cache.  Since the 601 has a unified cache, this
means that you don't have to worry about cache-coherency.  This means you
don't have to flush the processor cache.

The reason most people don't use BlockMove/BlockMoveData as a blitter is
that it will be very very slow if you ever use the screen as the
destination.  The reason is that the BlockMove/BlockMoveData routines use
the PPC instruction DCBZ.  This instruction will cause a data-exception
fault if the address supplied is not copy-back cacheable.  The screen
isn't marked copy-back cacheable.

Hope this helps,
Cameron Esfahani

+++++++++++++++++++++++++++

>From [e-mail] (Nick Porcino)
Date: 20 Nov 1995 20:35:30 GMT
Organization: Planet IX

In article <[e-mail]>,
[e-mail] (Erichsen) wrote:

>I did some tests (modifying the code in MoveData app from Tricks of the
>Mac Game Programming Gurus) between using doubles in a loop and BlockMove
>in a loop and BlockMove still blew it away (200 ticks vs 146 ticks for
>BlockMove) so why don't more people use BlockMove?
>
>I compared BlockMove vs BlockMoveData and found no difference at all (both
>146 ticks). Does BlockMove not flush the cache on a 6100?
>
>One of the replies to my previous question of why people don't just use
>BlockMove instead of a copying loop was that the data is not necessarily a
>block but, all the examples of blitters I've seen just copy one contiguous
>block of memory to another contiguous block of memory. Why couldn't
>BlockMove be used?

We did some tests and found on a Q700 that BlockMoveData was faster than
BlockMove in the context of an actual game (Riddle of Master Lu)

- Nick Porcino
Lead Engine Guy
Sanctuary Woods

+++++++++++++++++++++++++++

>From [e-mail] (Andrew Meggs)
Date: Tue, 21 Nov 1995 02:55:08 GMT
Organization: University of Virginia

In article <[e-mail]>,
[e-mail] (Erichsen) wrote:

> I did some tests (modifying the code in MoveData app from Tricks of the
> Mac Game Programming Gurus) between using doubles in a loop and BlockMove
> in a loop and BlockMove still blew it away (200 ticks vs 146 ticks for
> BlockMove) so why don't more people use BlockMove?
>

This got me interested, so I went and disassembled BlockMove. Surprisingly,
they aren't using doubles:

  BlockMove
     +00060 40A1C558   lwz        r5,0x0000(r3)
     +00064 40A1C55C   lwz        r6,0x0004(r3)
     +00068 40A1C560   lwz        r7,0x0008(r3)
     +0006C 40A1C564   lwz        r8,0x000C(r3)
     +00070 40A1C568   lwz        r9,0x0010(r3)
     +00074 40A1C56C   lwz        r10,0x0014(r3)
     +00078 40A1C570   lwz        r11,0x0018(r3)
     +0007C 40A1C574   lwz        r12,0x001C(r3)
     +00080 40A1C578   dcbz       0,r4
     +00084 40A1C57C   addi       r3,r3,0x0020
     +00088 40A1C580   dcbt       0,r3
     +0008C 40A1C584   stw        r5,0x0000(r4)
     +00090 40A1C588   stw        r6,0x0004(r4)
     +00094 40A1C58C   stw        r7,0x0008(r4)
     +00098 40A1C590   stw        r8,0x000C(r4)
     +0009C 40A1C594   stw        r9,0x0010(r4)
     +000A0 40A1C598   stw        r10,0x0014(r4)
     +000A4 40A1C59C   stw        r11,0x0018(r4)
     +000A8 40A1C5A0   stw        r12,0x001C(r4)
     +000AC 40A1C5A4   addi       r4,r4,0x0020
     +000B0 40A1C5A8   bdnz       BlockMove+00060


The performance win is in the dcbz/dcbt pair. I'm assuming you weren't
copying to video memory, because that's marked uncacheable, and dcbz will
severely hurt performance if your destination is uncacheable.

I probably would have written it more like this, personally. Does anyone
have any idea what makes Apple's better? (Assuming it is...)

;assume source, destination, and size are all 32-byte aligned
;set r3 to source address minus 8 and r4 to destination address minus 8
;set ctr to size >> 5

BlockMoveLoop
   lfd      fp0,8(r3)
   lfd      fp1,16(r3)
   lfd      fp2,24(r3)
   lfdu     fp3,32(r3)
   dcbz     0,r4
   dcbt     0,r3
   stfd     fp0,8(r4)
   stfd     fp1,16(r4)
   stfd     fp2,24(r4)
   stfdu    fp3,32(r4)
   bdnz     BlockMoveLoop

> I compared BlockMove vs BlockMoveData and found no difference at all (both
> 146 ticks). Does BlockMove not flush the cache on a 6100?
>

The unified instruction and data cache on the 601 wouldn't cause any
problems with treating code as data, so there's no need to maintain
coherency between the two. In other words, it shouldn't, but on the
604 it would need to.

--
_________________________________________________________________________
andrew meggs                               the one who dies with the most
[e-mail]                              AOL free trial disks wins
_________________________________________________________________________
dead tv software --==-- the next generation of 3D games for the macintosh
       <http://darwin.clas.virginia.edu/~apm3g/deadtv/index.html>

+++++++++++++++++++++++++++

>From [e-mail] (Tom Stromar)
Date: 21 Nov 1995 05:52:12 GMT
Organization: Island Internet Customer

>>I did some tests (modifying the code in MoveData app from Tricks of the
>>Mac Game Programming Gurus) between using doubles in a loop and BlockMove
>>in a loop and BlockMove still blew it away (200 ticks vs 146 ticks for
>>BlockMove) so why don't more people use BlockMove?

Hmmm, I thought I read somewhere that blockmove was only available on '040's
and up.  If this is the case, it would surely explain why most programmers
'laze' out and only use a copy loop.  Of course I could be completely off my
rocker.

Tom =:p

[e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (Cameron Esfahani)
Date: Wed, 22 Nov 1995 02:18:42 -0800
Organization: Apple Computer, Inc.

In article <48rpec$[e-mail]>, [e-mail] (Tom
Stromar) wrote:

> >>I did some tests (modifying the code in MoveData app from Tricks of the
> >>Mac Game Programming Gurus) between using doubles in a loop and BlockMove
> >>in a loop and BlockMove still blew it away (200 ticks vs 146 ticks for
> >>BlockMove) so why don't more people use BlockMove?
>
> Hmmm, I thought I read somewhere that blockmove was only available on '040's
> and up.  If this is the case, it would surely explain why most programmers
> 'laze' out and only use a copy loop.  Of course I could be completely off my
> rocker.
>
> Tom =:p
>
> [e-mail]

Uh, your off your rocker.  BlockMove has been around since Day 1.  Thats
why its trap # is so low...

Cameron Esfahani

+++++++++++++++++++++++++++

>From Mark Williams <[e-mail]>
Date: Wed, 22 Nov 95 09:42:32 GMT
Organization: Streetly Software


In article <[e-mail]>, Andrew Meggs writes:

>
> In article <[e-mail]>,
> [e-mail] (Erichsen) wrote:
>
> > I did some tests (modifying the code in MoveData app from Tricks of the
> > Mac Game Programming Gurus) between using doubles in a loop and BlockMove
> > in a loop and BlockMove still blew it away (200 ticks vs 146 ticks for
> > BlockMove) so why don't more people use BlockMove?
> >
>
> This got me interested, so I went and disassembled BlockMove. Surprisingly,
> they aren't using doubles:
>
>   BlockMove
>      +00060 40A1C558   lwz        r5,0x0000(r3)
>      +00064 40A1C55C   lwz        r6,0x0004(r3)
>      +00068 40A1C560   lwz        r7,0x0008(r3)
>      +0006C 40A1C564   lwz        r8,0x000C(r3)
>      +00070 40A1C568   lwz        r9,0x0010(r3)
>      +00074 40A1C56C   lwz        r10,0x0014(r3)
>      +00078 40A1C570   lwz        r11,0x0018(r3)
>      +0007C 40A1C574   lwz        r12,0x001C(r3)
>      +00080 40A1C578   dcbz       0,r4
>      +00084 40A1C57C   addi       r3,r3,0x0020
>      +00088 40A1C580   dcbt       0,r3
>      +0008C 40A1C584   stw        r5,0x0000(r4)
>      +00090 40A1C588   stw        r6,0x0004(r4)
>      +00094 40A1C58C   stw        r7,0x0008(r4)
>      +00098 40A1C590   stw        r8,0x000C(r4)
>      +0009C 40A1C594   stw        r9,0x0010(r4)
>      +000A0 40A1C598   stw        r10,0x0014(r4)
>      +000A4 40A1C59C   stw        r11,0x0018(r4)
>      +000A8 40A1C5A0   stw        r12,0x001C(r4)
>      +000AC 40A1C5A4   addi       r4,r4,0x0020
>      +000B0 40A1C5A8   bdnz       BlockMove+00060
>
>
> The performance win is in the dcbz/dcbt pair. I'm assuming you weren't
> copying to video memory, because that's marked uncacheable, and dcbz will
> severely hurt performance if your destination is uncacheable.
>
> I probably would have written it more like this, personally. Does anyone
> have any idea what makes Apple's better? (Assuming it is...)

consecutive stfd's stall both pipelines. This means that (assuming all cache hits) you get one fp
store every 3 cycles, compared with one integer store every cycle. The result is 12 cycles to
transfer 4 words using fp registers, but only 10 cycles using integer registers. (see page I-175 of
the 601 User manual).

> ;assume source, destination, and size are all 32-byte aligned
> ;set r3 to source address minus 8 and r4 to destination address minus 8
> ;set ctr to size >> 5
>
> BlockMoveLoop
>    lfd      fp0,8(r3)
>    lfd      fp1,16(r3)
>    lfd      fp2,24(r3)
>    lfdu     fp3,32(r3)
>    dcbz     0,r4
>    dcbt     0,r3
>    stfd     fp0,8(r4)
>    stfd     fp1,16(r4)
>    stfd     fp2,24(r4)
>    stfdu    fp3,32(r4)
>    bdnz     BlockMoveLoop
>

One other problem with your code (and presumably why apple use the apparently wasteful addi
instructions rather than load/store with update) is that your dcbt instruction comes too late... fp3
already contains the double at r3 by the time you hit the dcbt 0,r3 instruction, so it has no
effect. Much worse, the dcbz always touches the block you wrote the _previous_ time through the
loop...

this could easily be fixed by preloading r5 with 8 and writing

    dcbz     r5,r4
    dcbt     r5,r3

But you would still lose out on a 601. I _think_ it would be quicker on a 604, but i've not
checked.
- --------------------------------------
Mark Williams<[e-mail]>

+++++++++++++++++++++++++++

>From [e-mail] (Tom Stromar)
Date: 23 Nov 1995 00:58:45 GMT
Organization: Island Internet Customer

>> Hmmm, I thought I read somewhere that blockmove was only available on
'040's
>> and up.  If this is the case, it would surely explain why most programmers
>> 'laze' out and only use a copy loop.  Of course I could be completely off
my
>> rocker.
>>
>> Tom =:p
>>
>> [e-mail]
>
>Uh, your off your rocker.  BlockMove has been around since Day 1.  Thats
>why its trap # is so low...
>
>Cameron Esfahani

Damnit, I hate it when I fall off this thing. I was confused between BlockMove
and that, that function, that... well.. I can't remember exactly but I'm sure
that the '040 had an 'instruction' (hence my confusion, long days at work
these days) that allowed larger chunks of data to be moved. Judging the way
*this* post is going, I'm definitely going to have to pay more attention to
what I read both on and off-line. My apologies.

Tom


(so what the hell is the name of that instruction? Am I still off my rocker?)

+++++++++++++++++++++++++++

>From [e-mail] (Eric A. Drumbor)
Date: Wed, 22 Nov 1995 20:41:49 -0700
Organization: BW Software

In article <490h05$[e-mail]>, [e-mail] (Tom
Stromar) wrote:

[sniperino]

>
> Damnit, I hate it when I fall off this thing. I was confused between
BlockMove
> and that, that function, that... well.. I can't remember exactly but I'm sure
> that the '040 had an 'instruction' (hence my confusion, long days at work
> these days) that allowed larger chunks of data to be moved. Judging the way
> *this* post is going, I'm definitely going to have to pay more attention to
> what I read both on and off-line. My apologies.
>
> Tom
>
>
> (so what the hell is the name of that instruction? Am I still off my rocker?)

     Ahem...Move16()?

--
"Ah, voice come from cow on wall!"
Eric A. Drumbor
[e-mail]                 <http://www.nilenet.com/~ericd/>
BW Software

+++++++++++++++++++++++++++

>From [e-mail] (Jason Newquist)
Date: 23 Nov 1995 03:14:15 GMT
Organization: Maxwell at UCD Physics

Tom Stromar ([e-mail]) wrote:

> (so what the hell is the name of that instruction? Am I still off my rocker?)

MOVE16 ?

Regards,
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Jason Newquist                          http://maxwell.ucdavis.edu/~newquist/
[e-mail]            eWorld - [e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (Staffan Svensson)
Date: 21 Nov 95 19:17:38 GMT
Organization: (none)

In article <48rpec$[e-mail]>
[e-mail] (Tom Stromar) writes:

> >>I did some tests (modifying the code in MoveData app from Tricks of the
> >>Mac Game Programming Gurus) between using doubles in a loop and BlockMove
> >>in a loop and BlockMove still blew it away (200 ticks vs 146 ticks for
> >>BlockMove) so why don't more people use BlockMove?
>
> Hmmm, I thought I read somewhere that blockmove was only available on '040's
> and up.  If this is the case, it would surely explain why most programmers
> 'laze' out and only use a copy loop.  Of course I could be completely off my
> rocker.

Well not quite... Blockmove has been around for as long as there has
been macs, but the special case BlockMoveData was introduced with the
040. I don't have any figures on the speed differences between these
routines however, but, basically, BlockMove flushes the instruction
cache and BlockMoveData does not.

____________________ ____ ___ _ _  _   _     _
 Staffan Svensson
 neonWare CESD

+++++++++++++++++++++++++++

>From [e-mail] (Cameron Esfahani)
Date: Tue, 28 Nov 1995 01:24:06 -0800
Organization: Apple Computer, Inc.

Actually no, BlockMoveData was introduced with System 7.5.  The code for
it was kicking around Apple for a little while before we had a shipping
vehicle for it.

Cameron Esfahani


In article <[e-mail]>, [e-mail] (Staffan Svensson) wrote:

>
> Well not quite... Blockmove has been around for as long as there has
> been macs, but the special case BlockMoveData was introduced with the
> 040. I don't have any figures on the speed differences between these
> routines however, but, basically, BlockMove flushes the instruction
> cache and BlockMoveData does not.
>
> ____________________ ____ ___ _ _  _   _     _
>  Staffan Svensson
>  neonWare CESD

+++++++++++++++++++++++++++

>From [e-mail] (Deirdre)
Date: Tue, 28 Nov 1995 14:46:04 GMT
Organization: Tarla's Secret Clench

BlockMove was available in System 1.0. However, the distinction between
BlockMove and the newer call BlockMoveData is only significant on 040s and
higher. On other machines it is the same trap.

_Deirdre

In article <48rpec$[e-mail]>, [e-mail] (Tom
Stromar) wrote:

> Hmmm, I thought I read somewhere that blockmove was only available
> on '040's and up.  If this is the case, it would surely explain
> why most programmers 'laze' out and only use a copy loop.  Of course
> I could be completely off my rocker.

+++++++++++++++++++++++++++

>From [e-mail] (Ken Prehoda)
Date: Wed, 29 Nov 1995 09:26:05 -0600
Organization: Univ of Wisconsin-Madison, Dept of Biochemistry

In article <[e-mail]>, [e-mail]
(Deirdre) wrote:

: BlockMove was available in System 1.0. However, the distinction between
: BlockMove and the newer call BlockMoveData is only significant on 040s and
: higher. On other machines it is the same trap.
:
: _Deirdre
:
: In article <48rpec$[e-mail]>, [e-mail] (Tom
: Stromar) wrote:
:
: > Hmmm, I thought I read somewhere that blockmove was only available
: > on '040's and up.  If this is the case, it would surely explain
: > why most programmers 'laze' out and only use a copy loop.  Of course
: > I could be completely off my rocker.

As far as I can tell BlockMoveData is _only_ significant on the 040.
BlockMove does not flush the cache on the PPC's.
_____________________________________________________________________________
Ken Prehoda                                              [e-mail]
Department of Biochemistry                         http://www.nmrfam.wisc.edu
University of Wisconsin-Madison                             Tel: [phone]
420 Henry Mall                                              Fax: [phone]

+++++++++++++++++++++++++++

>From [e-mail] (Cameron Esfahani)
Date: Wed, 29 Nov 1995 22:53:41 -0800
Organization: Apple Computer, Inc.

That is not true.  BlockMove does flush the cache on the new PPCs.  Any
PPC with a split cache (603/604 and any other ones) will require cache
flushing.  So,  BlockMove on a 601-based machine doesn't flush the cache
because it makes no sense, but on > 601-machines, it does flush.

Cameron Esfahani


In article <[e-mail]>,
[e-mail] (Ken Prehoda) wrote:

> As far as I can tell BlockMoveData is _only_ significant on the 040.
> BlockMove does not flush the cache on the PPC's.
> _____________________________________________________________________________
> Ken Prehoda                                              [e-mail]
> Department of Biochemistry                         http://www.nmrfam.wisc.edu
> University of Wisconsin-Madison                             Tel: [phone]
> 420 Henry Mall                                              Fax: [phone]

+++++++++++++++++++++++++++

>From [e-mail] (Mick Foley)
Date: Wed, 29 Nov 1995 22:23:29 -0800
Organization: "emf.net" Quality Internet Access.  [phone] (Voice)

In article <[e-mail]>,
[e-mail] (Ken Prehoda) wrote:

> As far as I can tell BlockMoveData is _only_ significant on the 040.
> BlockMove does not flush the cache on the PPC's.

Not on the 601 which has a unified cache. But it should make a big
difference on the 603 and 604 which have split data and code caches.

Mick

+++++++++++++++++++++++++++

>From Ed Wynne <[e-mail]>
Date: 4 Dec 1995 04:09:26 GMT
Organization: Arwyn, Inc.

In article <[e-mail]>
Cameron Esfahani, [e-mail] writes:
>That is not true.  BlockMove does flush the cache on the new PPCs.  Any
>PPC with a split cache (603/604 and any other ones) will require cache
>flushing.  So,  BlockMove on a 601-based machine doesn't flush the cache
>because it makes no sense, but on > 601-machines, it does flush.
>
>Cameron Esfahani
>

Actually, thats almost right...  BlockMoveData CAN cause cache flushing on
601-based machines if they are running the DR emulator.  The processor
cache
doesn't get flushed but the emulator's internal cache of recompiled code
does.  This process is probably a fair amount slower than the real on-chip
cache flush since it is a software based operation.

To my knowledge the only machines so-far with this configuration would be
the 7200 and 7500.  (does the 8500 have a 601 option?)

-ed




---------------------------

>From [e-mail] (Jeremy Tully)
Subject: Hiding the menu bar
Date: 27 Nov 1995 04:12:47 GMT
Organization: None

Does anyone know if there is a routine to hide the menu bar?  I looked
in my copy of Toolbox Essentials (don't have Think Reference __yet__),
and I couldn't find one.  I assume it could be something as simple as
HideMenuBar(), but I'm not sure (I looked in menus.h, but the closest I
could find was ClearMenuBar, whose function I'm not sure of). Thanks
for any help.

--
Why doesn't the Bat Computer crash?
--
[e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (Anders Wahlin)
Date: Tue, 28 Nov 1995 10:31:23 GMT
Organization: Hum Fak:s Dataservice

In article <49bdrv$[e-mail]>, [e-mail] (Jeremy
Tully) wrote:

> Does anyone know if there is a routine to hide the menu bar?  I looked
> in my copy of Toolbox Essentials (don't have Think Reference __yet__),
> and I couldn't find one.  I assume it could be something as simple as
> HideMenuBar(), but I'm not sure (I looked in menus.h, but the closest I
> could find was ClearMenuBar, whose function I'm not sure of). Thanks
> for any help.
>

This might help you (Copied from Symantec's THINK Reference 2.0)


/* CODE EXAMPLE #1 */
/*
 * How to hide the menubar
 * This code sample shows how to hide the menubar.  It isn't something that you
 * should really be doing (see the Apple Q&A stack for more), and the extra
 * space might not 'work' ok (ie, it might not receive mouse-clicks and
such), but
 * it will enable you to draw on (or just obscure) the menu bar. Also, you
should
 * avoid calling ExitToShell without first calling ShowMenuBar, because you'll
 * find that you have no menu bar. This code hasn't been tested with
multiple monitor
 * environments.
 */

// Assumes inclusion of <MacHeaders>

void Init(void);
void HideMenuBar(void);
void ShowMenuBar(void);

void
Init(void)
{
   InitGraf(&thePort);
   InitFonts();
   InitWindows();
   TEInit();
   InitDialogs(nil);
   InitCursor();
}

short oldMBarHeight;
RgnHandle   mBarRgn;

void HideMenuBar()
{
   Rect  mBarRect;

   oldMBarHeight = GetMBarHeight();
   MBarHeight = 0;         /* make the Menu Bar's height zero */
   SetRect(&mBarRect, screenBits.bounds.left, screenBits.bounds.top,
         screenBits.bounds.right, screenBits.bounds.top + oldMBarHeight);
   mBarRgn = NewRgn();
   RectRgn(mBarRgn, &mBarRect);
   UnionRgn(GrayRgn, mBarRgn, GrayRgn);/* tell the desktop it covers the menu
                                        * bar
                                        */
   PaintOne(nil, mBarRgn); /* redraw desktop */
}

void ShowMenuBar()
{
   MBarHeight = oldMBarHeight;   /* make the menu bar's height normal */
   DiffRgn(GrayRgn, mBarRgn, GrayRgn); /* remove the menu bar from the
                                        * desktop
                                        */
   DisposeRgn(mBarRgn);
}

main()
{
   Init();
   HideMenuBar();
   while (!Button())
         ;
   ShowMenuBar();
}

--
Anders Wahlin
[e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (Thomas Aaron Insel)
Date: 28 Nov 95 06:58:22 GMT
Organization: Defenestrating Illini, Urbana Illinois

[e-mail] (Jeremy Tully) writes:

> Does anyone know if there is a routine to hide the menu bar?  I looked
> in my copy of Toolbox Essentials (don't have Think Reference __yet__),
> and I couldn't find one.  I assume it could be something as simple as
> HideMenuBar(), but I'm not sure (I looked in menus.h, but the closest I
> could find was ClearMenuBar, whose function I'm not sure of). Thanks
> for any help.

I don't think it's quite that simple, and I don't know the answer, but
I'm nearly positive that there's sample code somewhere on
http://dev.info.apple.com for exactly this.

Tom
--
Thomas Insel ([e-mail])
  "Republicans understand the importance of bondage between a mother and
   child." -- Vice President Dan Quayle

+++++++++++++++++++++++++++

>From catambay#m#[e-mail] (Bill the Cat)
Date: 30 Nov 1995 23:13:42 GMT
Organization: MacPascal Mailing List

In article <49bdrv$[e-mail]>, [e-mail] (Jeremy
Tully) wrote:

> Does anyone know if there is a routine to hide the menu bar?  I looked
> in my copy of Toolbox Essentials (don't have Think Reference __yet__),
> and I couldn't find one.  I assume it could be something as simple as
> HideMenuBar(), but I'm not sure (I looked in menus.h, but the closest I
> could find was ClearMenuBar, whose function I'm not sure of). Thanks
> for any help.
>
> --
> Why doesn't the Bat Computer crash?
> --
> [e-mail]

No built-in function for doing this, but here's some code that does:

Var
   save_mbar:   integer;
   mBarRgn:    rgnHandle;
   GrayRgn:    RgnHandle;

Procedure SH_ForceUpdate(rgn: RgnHandle);

Var
   wpFirst: WindowRef;

   begin
   wpFirst := LMGetWindowList;
   PaintBehind(wpFirst, rgn);
   CalcVisBehind(wpFirst, rgn);
   end;

Procedure GetMBarRgn(mbarRgn: RgnHandle);

Var
   mbarRect:   Rect;

   begin
   mBarRect := qd.screenBits.bounds;
   mBarRect.bottom := mBarRect.top + save_mbar;
   RectRgn(mBarRgn, mBarRect);
   end;

Procedure RemoveMbar;

   begin
   save_mbar := GetMBarHeight;
   mBarRgn := NewRgn;
   GetMBarRgn(mBarRgn);          { make a region for the mbar }
   LMSetMBarHeight(0);
   GrayRgn := LMGetGrayRgn;
   UnionRgn(GrayRgn,mBarRgn,GrayRgn);
   SH_ForceUpdate(mBarRgn);
   end;

Procedure ResetMbar;

   begin
   LMSetMBarHeight(save_mbar);
   DiffRgn(GrayRgn, mBarRgn, GrayRgn);
   DisposeRgn(mBarRgn);          { dispose the bar region }
   DrawMenuBar;
   end;

_____________________________________________________________________
Bill Catambay
Pascal Programmer on Macintosh and Open VMS

              />
             //   The purpose of software engineering
     (//////[O]>=========================================-
             \\    is to manage complexity, not to create it.
              \>

____________________________________________________________________

+++++++++++++++++++++++++++

>From Darren Giles <[e-mail]>
Date: Fri, 1 Dec 1995 21:25:12 GMT
Organization: NETCOM On-line Communication Services (408 261-4700 guest)

>> Does anyone know if there is a routine to hide the menu bar?
>
>No built-in function for doing this, but here's some code that does:


Actually, there is now support for this... in QuickTime, interestingly
enough.  Check out the QT 2.1 API, if that works for you.

- Darren

==========================================================================
Darren Giles, Technical Director                        Terran Interactive
For info on Cleaner QuickTime compression, visit http://www.terran-int.com

+++++++++++++++++++++++++++

>From [e-mail] (Mountain Dew Man!)
Date: 5 Dec 1995 08:13:05 GMT
Organization: University of Alaska Fairbanks

Sorry not to post to the original message, I missed it.

There are a pair of routines as part of videotoolbox (available on
infomac in the programming area under libraries I believe).  It is in the
file HideMenuBar.c which also has ShowMenuBar, SquareCorners, and
RestoreCorners to allow you to use your whole screen and put it back again.

Also note there are gobs of other routines in that package, which by the
way was intended for use by some branch of psychologists, but many are
designed around being fast and for grpahical manipulations, and well
suited for games in many ways.

See Yah!

Thomas Aaron Insel ([e-mail]) wrote:
: [e-mail] (Jeremy Tully) writes:

: > Does anyone know if there is a routine to hide the menu bar?  I looked
: > in my copy of Toolbox Essentials (don't have Think Reference __yet__),
: > and I couldn't find one.  I assume it could be something as simple as
: > HideMenuBar(), but I'm not sure (I looked in menus.h, but the closest I
: > could find was ClearMenuBar, whose function I'm not sure of). Thanks
: > for any help.

: I don't think it's quite that simple, and I don't know the answer, but
: I'm nearly positive that there's sample code somewhere on
: http://dev.info.apple.com for exactly this.

: Tom
: --
: Thomas Insel ([e-mail])
:   "Republicans understand the importance of bondage between a mother and
:    child." -- Vice President Dan Quayle

--
_____________________________________________________________________
Seann Woolery  --  Running in circles does that to you...
_____________________________________________________________________
[e-mail]
_____________________________________________________________________

---------------------------

>From [e-mail] (John Purlia)
Subject: MoveControl and popup menus
Date: Mon, 27 Nov 1995 12:56:56 -0800
Organization: QUALCOMM, Inc.
Today's toolbox teaser:

How do you (safely) relocate the standard popup menu control WITHOUT
calling MoveControl?

MoveControl has the annoying habit of calling both HideControl and
ShowControl to first erase, move, then redisplay a control.  Trouble is,
there are circumstances under which you might not want to perform all that
redrawing, instead intending to simply move the control's location in the
window.  For example, a call to ScrollRect moves a control "visually" and
smoothly, however the control itself still needs to be moved in order to
respond to subsequent hits, etc.  Calling MoveControl performs the
necessary relocation, albeit with the ugly cost of first erasing the
control's previous location, then redrawing over the new location (again
erasing over the previously scrolled control).

No big deal, there are a couple of easy ways to attain the desired results:

1. Don't call MoveControl.  Instead, relocate the control's rectangle
   exlicitly like so:

        OffsetRect (&(*theControl)->contrlRect, h, v);

   Works fine, it's fast, and it creates the illusion of the control moving
   after the window's been scrolled.  Of course, it also runs the risk of
   breaking in the future if the structure of the control record changes.

2. Call MoveControl, but only after first making the control invisible.  Trouble
   is, you again can't make the control invisible via the toolbox because
   HideControl erases, so you end up with something like this:

        (*theControl)->contrlVis = 0;
        MoveControl (theControl, left, top);
        (*theControl)->contrlVis = 255;

   Again, this works, but once again at the risk of future incompatibility.

3. Go nuts with the clip region (paraphrasing):

        // save the clip region
        // create a new clip region
        // subtract the control's original location from the new clip region
        // subtract the control's new location from the new clip region
        // Set the new clip region
        MoveControl (theControl, left, top);
        // Set the saved clip region

   Seems clean and correct, but it is terribly inefficient and VERY slow when
   all that is intended is to simply relocate the control's bounding rectangle.


For the standard button controls, either approach 1 or 2 is really good
enough to achieve the desired results.  Popup menu controls, however, are
another story.

Moving the popup's control rectangle as in approach 1 does not completely
move the control.  Though the test area of the control *is* moved to the
correct location, clicks in the control popup the menu in the previous
control location.

Likewise, approach 2 -- though MoveControl *is* being called -- does not
fully relocate all the pieces of the popup control.  In this case,
subsequent calls to Draw1Control first erase the old location before
drawing in the location we just moved to.  Weird!!  A call to MoveControl
should move ALL portions of a control regardless of whwther or not the
control is visible -- which is apparently not the case when dealing with
the standard popup control.

So...  How can the standard popup control be relocated without calling
MoveControl?  From walking through popup CDEF is looks like part of the
popup private data record stored in the control's contrlData field
contains one or more rectangles or points used to specify the location of
the menu portion of the control (the part that appears to do all the
erasing).  Though it may be viewed as evil and against the rules, I'd like
to be able to explicitly set this rectangle to the "new" location of the
popup after it has been scrolled.

Of course, if the Control Manager sported a RelocateControl command, or
even safe accessor functions to the control record, I wouldn't now feel so
underhanded.  :)

Thanks!

-- John

+++++++++++++++++++++++++++

>From [e-mail] (Ari Halberstadt)
Date: Tue, 28 Nov 1995 07:22:58 -0400
Organization: North Shore Access/Eco Software, Inc; ([e-mail])

In article <[e-mail]>,
[e-mail] (John Purlia) wrote:
>3. Go nuts with the clip region (paraphrasing):
>
>        // save the clip region
>        // create a new clip region
>        // subtract the control's original location from the new clip region
>        // subtract the control's new location from the new clip region
>        // Set the new clip region
>        MoveControl (theControl, left, top);
>        // Set the saved clip region
>
>   Seems clean and correct, but it is terribly inefficient and VERY slow when
>   all that is intended is to simply relocate the control's bounding rectangle.
>

This is the best solution. I use a similar approach and it works nicely.
You don't really need to do the math with the clip region: just set it to
an empty region before calling MoveControl. The inefficiency is minimal.
Allocating a region is fast (you could preallocate it and store it in a
private static if you were really concerned). Getting and setting the clip
region are fast (setting it is especially fast). QuickDraw always checks
against the clip region before drawing, and is probably optimized to
handle an empty clip region.

/* Definitions for Strict Controls (until Apple provides them) */
#if ! STRICT_CONTROLS
   #define IsControlVisible(ctl)    (((**((ControlHandle) ctl)).contrlVis) != 0)
   #define GetControlHilite(ctl)    ((**((ControlHandle) ctl)).contrlHilite)
   #define GetControlData(ctl)      ((**((ControlHandle) ctl)).contrlData)
   #define GetControlRect(ctl, r)   ((void) ((*r) = (**((ControlHandle)
ctl)).contrlRect))
   #define GetControlOwner(ctl)     ((**((ControlHandle) ctl)).contrlOwner)
   #define GetControlDefProc(ctl)   ((**((ControlHandle) ctl)).contrlDefProc)
#endif

void RelocateControl(ControlHandle inControl, short inLeft, short inTop)
{
   RgnHandle oldClipRgn = NewRgn();
   RgnHandle emptyClipRgn = NewRgn();
   GrafPtr oldPort = NULL;
   assert(oldClipRgn && emptyClipRgn);
   GetPort(&oldPort);
   SetPort(GetWindowPort(GetControlOwner(inControl)));
   GetClip(oldClipRgn);
   SetClip(emptyClipRgn);
   MoveControl(inControl, inLeft, inTop);
   SetClip(oldClipRgn);
   SetPort(oldPort);
   DisposeRgn(oldClipRgn);
   DisposeRgn(emptyClipRgn);
}

>Likewise, approach 2 -- though MoveControl *is* being called -- does not
>fully relocate all the pieces of the popup control.  In this case,

Sounds like a bug in the popup CDEF.

>So...  How can the standard popup control be relocated without calling
>MoveControl?  From walking through popup CDEF is looks like part of the
>popup private data record stored in the control's contrlData field
>contains one or more rectangles or points used to specify the location of
>the menu portion of the control (the part that appears to do all the
>erasing).  Though it may be viewed as evil and against the rules, I'd like
>to be able to explicitly set this rectangle to the "new" location of the
>popup after it has been scrolled.

Not a good idea. Will break in a different version.

-- Ari Halberstadt ([e-mail], [e-mail])
<http://www.shore.net/~ari/> (under construction)

---------------------------

>From [e-mail] (Mage Steve)
Subject: Non-resource custom PowerPC LDEF
Date: 24 Nov 1995 03:48:16 -0500
Organization: America Online, Inc. (1-800-827-6364)

Anyone know this one?

I wish to use the List Manager to display some information using a custom
LDEF.  I do not want the LDEF to be a resource, but instead to be an
internal function in my code.  How do I do this under the new PowerPC
methods?  I have some old Pascal code that does this by creating a pointer
to my function, then setting the listDefProc field of the list handle to
point to the pointer (the field expects a handle to the function, this
fools it).  I expect similiar method would work in C++, but I am concern
about how to write it in PowerPC Native code.

Any comments anyone?

Please drop a note online AND email it to me!

Thanks!

Steve Sheets
Mageware

+++++++++++++++++++++++++++

>From [e-mail] (Bo Lindbergh)
Date: 25 Nov 1995 07:26:33 GMT
Organization: Royal Institute of Technology, Stockholm, Sweden

static pascal void mylistdef(
    short lMessage,
    Boolean lSelect,
    Rect *lRect,
    Cell lCell,
    short lDataOffset,
    short lDataLen,
    ListRef lHandle)
{
    /* whatever... */
}

static RoutineDescriptor mylistdefdesc =
    BUILD_ROUTINE_DESCRIPTOR(uppListDefProcInfo,mylistdef);

static void setupldef(void)
{
    Handle ldefh;

    ldefh=Get1Resource('LDEF',myldefid);
    SetHandleSize(ldefh,sizeof (RoutineDescriptor));
    **(RoutineDescriptorHandle)ldefh=mylistdefdesc;
}



+++++++++++++++++++++++++++

>From [e-mail] (Owen Hartnett)
Date: Sat, 25 Nov 1995 11:02:28 -0600
Organization: IDS World Network Internet Access Service, [phone]

In article <4940sg$[e-mail]>, [e-mail] (Mage
Steve) wrote:

> Anyone know this one?
>
> I wish to use the List Manager to display some information using a custom
> LDEF.  I do not want the LDEF to be a resource, but instead to be an
> internal function in my code.  How do I do this under the new PowerPC
> methods?  I have some old Pascal code that does this by creating a pointer
> to my function, then setting the listDefProc field of the list handle to
> point to the pointer (the field expects a handle to the function, this
> fools it).  I expect similiar method would work in C++, but I am concern
> about how to write it in PowerPC Native code.
>

The NewsWatcher source, available for ftp, does this.

-Owen

+++++++++++++++++++++++++++

>From Matt Slot <[e-mail]>
Date: 1 Dec 1995 02:18:34 GMT
Organization: University of Michigan

Mage Steve, [e-mail] writes:
 > I wish to use the List Manager to display some information using a custom
 > LDEF.  I do not want the LDEF to be a resource, but instead to be an
 > internal function in my code.  How do I do this under the new PowerPC
 > methods?  I have some old Pascal code that does this by creating a pointer
 > to my function, then setting the listDefProc field of the list handle to
 > point to the pointer (the field expects a handle to the function, this
 > fools it).  I expect similiar method would work in C++, but I am concern
 > about how to write it in PowerPC Native code.

Try this sample code, which uses a PPC RoutineDescriptor for the LDEF stub:


Handle SetupCallbackLDEF() {
        Handle stubHandle;

#if !GENERATINGPOWERPC
        ProcPtr proc = (ProcPtr) myLDEFProc;

        stubHandle = NewHandle(6);
        if (! stubHandle) return(0);

        (* (short **) stubHandle)[0] = 0x4EF9;  // 68K jump instruction
        BlockMove(&myLDEFProc, *stubHandle + 4, sizeof(myLDEFProc));

        // Flush the cache here...

#else
        RoutineDescriptor
                rd = BUILD_ROUTINE_DESCRIPTOR(uppListDefProcInfo, myLDEFProc);

        stubHandle = NewHandle(sizeof(rd));
        if (! stubHandle) return(0);

        BlockMoveData(&rd, *(*gHdl)->MimeListDef, sizeof(rd));
#endif

        return(stubHandle);
        }


Of course, I am think you really should load the LDEF stub's handle from
a resource, pass the resID to the LNew() call, and then detach it. Remember
that LNew() passes an Init message to the LDEF... and you don't want to let
the system LDEF get that message, or you will get a memory leak when it
allocates data.

Also, if you want to avoid flushing the cache in the 68K code, you can
replace the "6-byte" trick with longer, but safer, inline assembler:


asm void NoFlushStub() {
        bra.s   @past_data
@data:
        dc.l    0                               ; The ProcPtr gets inserted here
@past_data:
        move.l  @data, a0
        jmp             (a0)
        }


Disassemble this, and you can stuff it into your handle as normal. Since
it never really modifies a 68K instruction, you don't have to flush the
cache (the move.l loads the procptr from the data cache). Of course, the
PPC routine descriptor is never executed whether called from PPC (CallUPP
simply dispatches to the ProcPtr) or from 68K (its "executed" by the
emulator, and never hits the instruction cache).

Good Luck!

Matt

---------------------------

>From [e-mail] (Jerry Adlersfluegel)
Subject: OpenDoc lingo
Date: Fri, 01 Dec 1995 01:20:51 -0600
Organization: Washington University in St. Louis, MO USA

I've been reading all this OpenDoc stuff, and follow it pretty well. (I'm
no programmer.) But there's one thing that's kind of bugging me.

It seems people (myself included) are confused about all the terms: part,
document, container, editor, etc. Container is used instead of document,
editors are called parts, documents are called parts, editors are called
containers, and so on.

For all of our sakes, could someone please list the 'real' definitions for
the above terms (and whatever I didn't include).

I have a pretty good idea of what they all are, but I would like to see
them clarified here for everyone.

Thanks!

--
Jerry Adlersfluegel                 (from my gf's account because
[e-mail]                     my school's systems bite)
                    <<Smilie free zone>>

+++++++++++++++++++++++++++

>From Kerry Ortega <[e-mail]>
Date: 1 Dec 1995 20:04:17 GMT
Organization: Apple

In article <[e-mail]> Jerry
Adlersfluegel, [e-mail] writes:
>no programmer.) But there's one thing that's kind of bugging me.


I guess the confusion is that many of the terms are very closely related.
For example a Document is a collection of parts but always contains
something called a root part.  To an end user the root part and the
Document are the same thing.  If the root part allows embedding it's also
a container part and so forth.  Below are some common OpenDoc terms.  I
hope this helps clear up some of the confusion.

Kerry Ortega
Apple's OpenDoc Human Interface Team


Document - In OpenDoc, a user-organized collection of parts, all stored
together.

Compound document - A single document containing multiple heterogeneous
data types, each presented and edited by its own software. A compound
document is made up of parts.

Draft - A version of a document, defined at a certain point in time by
the user. A document is made up of a set of drafts.

Part - A portion of a compound document; it consists of document content,
plus-at runtime-a part editor that manipulates that content. The content
is data of a given structure or type, such as text, graphics, or video;
the code is a part editor.

Container part - A part that is capable of embedding other parts within
its content

Embedding  - One part is inserted into the contents of another part. The
inserted part maintains its part identity. The receiving part decides
layout issues such as whether the new part overlaps existing parts in its
contents.

Root part - The part that forms the base of a document and establishes
its basic editing, embedding, and printing behavior. A document has only
one root part, which can contain content elements and perhaps other,
embedded parts. Any part can be a root part.


Stationery - A part which has the Stationery property set. The only
difference between a normal part and a stationery part is in the Open
behavior. When you open a normal part, it opens into a window. When you
open a stationery part, it creates ("tears off") a new part, saves the
copy to disk with a unique name, and opens that copy, leaving the
stationery unchanged. Thus stationery is just an accelerator for
duplicating an existing part and then opening it. This allows documents
containing boiler-plate to be easily used to create new documents. We
encourage developers to deliver their parts as stationery pads, since
this will prevent accidentally modifying the original.

Hot part - A part, such as a button, that performs an action (like
running a script), rather than activating itself, when it receives a
mouse click.


Part editor - An OpenDoc component that can display and change the data
of a part. It is the executable code that provides the behavior for the
part. Compare part viewer.

Part viewer - A part editor that can display and print, but not change,
the data of a part. Compare part editor.


Part Contents - In general, a part can contain two types of data:
intrinsic contents and other parts. There is no requirement that parts be
able to do contain other parts, and some won't be able to. But a key
characteristic of OpenDoc is that if a part can contain one kind of part,
it can contain all kinds of parts, since OpenDoc supplies a uniform
wrapper for parts. (Contrast this with the small number of standard data
types supported today, such as text, PICT,
TIFF, etc.)

Intrinsic Contents - Data which is intrinsic to a particular type of
part. For example, text parts contain characters. Graphics parts may
contain lines and circles. Spreadsheet parts contain spreadsheet cells.
Video parts contain digitized video. Sound parts contain digitized sound.
Simulation parts contain executable code. And so on. The part developer
determines what intrinsic contents a part may contain.


Part category  - A general classification of the format of data handled
by a part editor. Categories are broad classes of data format, meaningful
to end users, such as "text", "graphics" or "table". Compare part kind.

Part kind  - A specific classification of the format of data handled by a
part editor. A kind specifies the specific data format handled by a part
editor. Kinds are meaningful to end users, and have designations such as
such as "MacWrite 2.0" or "QuickTime 1.0". Compare part category.


Active / Inactive Parts - A part may be active or inactive. Being active
means that the part contains the selection (or caret). For a part to be
active, its contents must be visible, i.e. it must be displayed in a
window or frame. Normally the active part receives commands and keyboard
events, and its frame border, menu, palettes, and other user interface
techniques are displayed. At most one part is active at a time. A part is
made active by user actions such as clicking the mouse or dragging
something into its contents. When a part is activated, the previously
active part, if any, becomes inactive. The frame border, menu, palettes,
etc. of inactive parts are not displayed. Being inactive does not mean
that a part isn't running. Parts may execute asynchronously whether they
are active or inactive, even if they are displayed as icons.

+++++++++++++++++++++++++++

>From [e-mail] (Scott Howlett)
Date: Fri, 1 Dec 1995 19:26:49 GMT
Organization: (or lack thereof)

In article <...m>, [e-mail] (Eric Jackson) wrote:
..
> >For all of our sakes, could someone please list the 'real' definitions for
> >the above terms (and whatever I didn't include).

> Part:
>
> This is an OpenDoc part.  There are two types of parts called editors and
> viewers.  There is another way that OpenDoc parts can differ.  Some parts
> called container parts can have other parts embeded inside of them.
>
> If you want to see your OpenDoc parts you can look in your Editors folder
> because that is where they live.

Umm, doesn't "Part" refer to the data itself? The thing you use to edit
a part is a "part editor" and the thing you use to just look at a part
in the absence of a part editor is a "part viewer".

Or am I mistaken?

- Scott

--
Scott Howlett, [e-mail]
"Probably the earliest fly swatters were nothing more than some sort of
striking surface attached to the end of a long stick."

+++++++++++++++++++++++++++

>From Kerry Ortega <[e-mail]>
Date: 1 Dec 1995 23:17:15 GMT
Organization: Apple

Oh I forgot to mention that OpenDoc terms are defined on the CILabs
website as well.

Checkout http://www.cilabs.org/docs/glossary.html

Kerry Ortega

+++++++++++++++++++++++++++

>From [e-mail] (Donna Kellee Kramer)
Date: 2 Dec 1995 03:56:58 GMT
Organization: College of Arts and Sciences -- Washington University, St. Louis, Missouri, USA

Scott Howlett ([e-mail]) wrote:
> In article <...m>, [e-mail] (Eric Jackson) wrote:
> ..
> > >For all of our sakes, could someone please list the 'real' definitions for
> > >the above terms (and whatever I didn't include).

> > Part:
> >
> > This is an OpenDoc part.  There are two types of parts called editors and
> > viewers.  There is another way that OpenDoc parts can differ.  Some parts
> > called container parts can have other parts embeded inside of them.
> >
> > If you want to see your OpenDoc parts you can look in your Editors folder
> > because that is where they live.

> Umm, doesn't "Part" refer to the data itself? The thing you use to edit
> a part is a "part editor" and the thing you use to just look at a part
> in the absence of a part editor is a "part viewer".

> Or am I mistaken?

I think you are right. "Part" is Apple's "civilian" word for "Object."

And a container is a special editor that contains several editors or
viewers. That's kind of the short route to porting an application to OD.

We _need_ a nomenclature guide, here.



+++++++++++++++++++++++++++

>From [e-mail] (Jerry Adlersfluegel)
Date: Sun, 03 Dec 1995 12:58:37 -0600
Organization: Washington University in St. Louis, MO USA
In article <49nn41$[e-mail]>, Kerry Ortega <[e-mail]> wrote:

[Everything I wanted to see!]


Thank you, Kerry.

--
Jerry Adlersfluegel                 (from my gf's account because
[e-mail]                     my school's systems bite)
                    <<Smilie free zone>>

+++++++++++++++++++++++++++

>From [e-mail] (Fletcher Sandbeck)
Date: 3 Dec 1995 20:38:36 GMT
Organization: Massachusetts Institute of Technology

>It seems people (myself included) are confused about all the terms: part,
>document, container, editor, etc. Container is used instead of document,
>editors are called parts, documents are called parts, editors are called
>containers, and so on.

Disclaimer: This is what I think the terms mean.  I may be wrong.

The two essential pieces of OpenDoc are Editors and Parts.

A Part is an element which you see on the screen as 'part' of
a document.  It contains data which can be manipulated or controls.

A Text Part is a region of text, a picture part is a region which
contains a picture.  There can also be Clock parts which display
clocks, button parts, and so-on.


An Editor is the program which controls how you interact with
the data and controls in its associated Parts.

So, when you are typing text into a Text Part, the Text Editor
has control.  When you are painting in a Picture Part, the Picture
Editor has control.


Companies will make and sell Part Editors, just as they sell
Applications today.  Users will create Parts with those Editors
just as they create Documents today.


A Document is a collection of Parts which are all saved together.
The Document belongs to the Part Editor of the uppermost (outermost)
Part.  If a user wants to create a document which is primarily Text
then they will use a Text Part as the base for the Document and when
the Document is saved it will look like a Text File in the Finder.


A Container is any Part which can contain other Parts.  Parts are
said to be Embedded in Containers.  Any Part can be embedded, but
special coding is required to make a Container Part.


Applications can also be Containers.  The Application is not a part
of OpenDoc itself (it cannot be embedded), but it can Contain any
OpenDoc parts.  In this way, Applications can support OpenDoc without
much special coding.


I hope this helps and doesn't sow more confusion.  There is a lot
more than this to OpenDoc too, BTW.

[fletcher]

+++++++++++++++++++++++++++

>From [e-mail] (Jeff Amfahr)
Date: Mon, 04 Dec 1995 10:17:32 -0400
Organization: Pharos Technologies

In article <49nn41$[e-mail]>, Kerry Ortega <[e-mail]> wrote:
> Document - In OpenDoc, a user-organized collection of parts, all stored
> together.
>
> Part - A portion of a compound document; it consists of document content,
> plus-at runtime-a part editor that manipulates that content. The content
> is data of a given structure or type, such as text, graphics, or video;
> the code is a part editor.
>
> Stationery - A part which has the Stationery property set. The only
> difference between a normal part and a stationery part is in the Open
> behavior. When you open a normal part, it opens into a window. When you
> open a stationery part, it creates ("tears off") a new part, saves the
> copy to disk with a unique name, and opens that copy, leaving the
> stationery unchanged. Thus stationery is just an accelerator for
> duplicating an existing part and then opening it. This allows documents
> containing boiler-plate to be easily used to create new documents. We
> encourage developers to deliver their parts as stationery pads, since
> this will prevent accidentally modifying the original.

One thing looks inconsistent with this set of definitions (and the one on
http://www.cilabs.org/docs/glossary.html also). The definition of
Stationery
is " A part which has the Stationery property set...When you open a normal
part...". However, it seems as if earlier defs of Document and Part seem
to indicate that Document is an on-disk item and Part is an in-memory
item. In fact, the Develop article "The OpenDoc User Experience" makes
this exact distinction, that parts on disk are always called documents.
This seem to be at odds with the definition of stationary (which may in
fact be a collection of parts, since I can make any document a stationary
document). In addition, to refer to an on disk item as a part seems
confusing, since it is not possible from looking at to tell if is in fact
one part or a collection of parts. So, is an on disk representation of a
part or collection of parts always refereed to as a document? If so, its
seems like the stationary definition is wrong.

  Jeff Amfahr
  Pharos Technologies
  [e-mail]

--
Jeff Amfahr
[e-mail]
 "This isn't right.  This isn't even wrong."
                                Wolfgang Pauli

+++++++++++++++++++++++++++

>From [e-mail] (John Anderson)
Date: 5 Dec 1995 21:17:57 GMT
Organization: Semiosis Unlimited

In message <[e-mail]> - [e-mail] (Jef
f Amfahr) writes:
>
>In article <49nn41$[e-mail]>, Kerry Ortega <[e-mail]> wrote:
>> Document - In OpenDoc, a user-organized collection of parts, all stored
>> together.
>>
>> Part - A portion of a compound document; it consists of document content,
>> plus-at runtime-a part editor that manipulates that content. The content
>> is data of a given structure or type, such as text, graphics, or video;
>> the code is a part editor.
>>
>> Stationery - A part which has the Stationery property set. The only
>> difference between a normal part and a stationery part is in the Open
>> behavior. When you open a normal part, it opens into a window. When you
>> open a stationery part, it creates ("tears off") a new part, saves the
>> copy to disk with a unique name, and opens that copy, leaving the
>> stationery unchanged. Thus stationery is just an accelerator for
>> duplicating an existing part and then opening it. This allows documents
>> containing boiler-plate to be easily used to create new documents. We
>> encourage developers to deliver their parts as stationery pads, since
>> this will prevent accidentally modifying the original.
>
>One thing looks inconsistent with this set of definitions (and the one on
>http://www.cilabs.org/docs/glossary.html also). The definition of
>Stationery
>is " A part which has the Stationery property set...When you open a normal
>part...". However, it seems as if earlier defs of Document and Part seem
>to indicate that Document is an on-disk item and Part is an in-memory
>item. In fact, the Develop article "The OpenDoc User Experience" makes
>this exact distinction, that parts on disk are always called documents.
>This seem to be at odds with the definition of stationary (which may in
>fact be a collection of parts, since I can make any document a stationary
>document). In addition, to refer to an on disk item as a part seems
>confusing, since it is not possible from looking at to tell if is in fact
>one part or a collection of parts. So, is an on disk representation of a
>part or collection of parts always refereed to as a document? If so, its
>seems like the stationary definition is wrong.

I use document to refer to either the Bento file on disk, or the window in
which the user works with all the parts.

I figure that we should actually be using two sets of nomenclature. One for
developers and one for users. For a developer, 'part' can refer to several
things, depending on the context: a part of a Bento file; a part of an
onscreen document when bound with its editor; a part editor when speking
loosely, eg "I've just written a neato-nifty RTF part". A user isn't
interested in all these distinctions. To quote "The OpenDoc User Experience"
(loosely) the user's experienec of OpenDoc should be seamless. So IMHO a
part for a user is just the thing that gets a box drawn around it when they
click on it.

One of the problems I have in explaining this to developers who aren't
familiar with OpenDoc is that initially people like to have words that only
refer to one thing. It's only after we become familiar with the domain that
we are able to cope with 'semantic overloading'.

Phew. All that is at _least_ 0.03 (per hour, thanks)

bye
John Anderson
Absolute Systems























































+++++++++++++++++++++++++++

>From [e-mail] (Fletcher Sandbeck)
Date: 8 Dec 1995 03:09:21 GMT
Organization: Massachusetts Institute of Technology


>The definition of Stationery
>is " A part which has the Stationery property set...When you open a normal
>part...". However, it seems as if earlier defs of Document and Part seem
>to indicate that Document is an on-disk item and Part is an in-memory
>item. In fact, the Develop article "The OpenDoc User Experience" makes
>this exact distinction, that parts on disk are always called documents.
>This seem to be at odds with the definition of stationary (which may in
>fact be a collection of parts, since I can make any document a stationary
>document). In addition, to refer to an on disk item as a part seems
>confusing, since it is not possible from looking at to tell if is in fact
>one part or a collection of parts. So, is an on disk representation of a
>part or collection of parts always refereed to as a document? If so, its
>seems like the stationary definition is wrong.

Currently on the Mac every Application has a distinct environment,
there is a Finder environment, a Word environment, and an OpenDoc
environment.

The important distinction between Parts and Documents is that on
a present-day Mac you will not see Parts in the Finder.  Only
Documents have icons in the Finder.

When you open a Document from the Finder you enter the OpenDoc
environment.  At this point the distinction between Parts and
Documents becomes a bit fuzzy.  A Document is now a collection
of Parts that you save and open all together.  Any part can
be saved independently and become a new document.

Stationery is a kind of Document in the Finder.  When you open
a piece of Stationery then you end up with a collection of Parts,
a Document, in the OpenDoc environment.

I don't think this will be confusing in the end release.  I
think users will adapt to double clicking Stationery documents
to create new Documents reasonably quickly.

[fletcher]


+++++++++++++++++++++++++++

>From [e-mail] (Eric Jackson)
Date: Fri, 1 Dec 1995 18:26:07 GMT
Organization: NETCOM On-line Communication Services (408 261-4700 guest)

In article <[e-mail]>,
Jerry Adlersfluegel <[e-mail]> wrote:
>I've been reading all this OpenDoc stuff, and follow it pretty well. (I'm
>no programmer.) But there's one thing that's kind of bugging me.
>
>It seems people (myself included) are confused about all the terms: part,
>document, container, editor, etc. Container is used instead of document,
>editors are called parts, documents are called parts, editors are called
>containers, and so on.
>
>For all of our sakes, could someone please list the 'real' definitions for
>the above terms (and whatever I didn't include).
>
>I have a pretty good idea of what they all are, but I would like to see
>them clarified here for everyone.
>
>Thanks!
>
>--
>Jerry Adlersfluegel                 (from my gf's account because
>[e-mail]                     my school's systems bite)
>                    <<Smilie free zone>>

Well let me give it a try.

Part:

This is an OpenDoc part.  There are two types of parts called editors and
viewers.  There is another way that OpenDoc parts can differ.  Some parts
called container parts can have other parts embeded inside of them.

If you want to see your OpenDoc parts you can look in your Editors folder
because that is where they live.

Document:

A Document is an Icon that lives on top of you desk top.  In the old days there
was an applicatiion that knew how to open the document.  But now things have
changed.  A Document now knows how to open inself.  It uses OpenDoc parts
called editors or viewers to show the data inside of the document.
Some fancy applications called *Container Applications* can have
documents that have OpenDoc parts in them.

Container:

A container is something that has something inside of it.  Many different
things can be containers.  For example if your can has a spare tire in
the trunk it is a spare tire container.  Documents since they can contain
a part are called containers.  A part that contains another part is also
a container.  An application that can contain parts is also called a
container.  I don't think that OpenDoc really changes the definition
of the word container in any special way, in the sence that the
meaning of the word part, in the OpenDoc context has been changed.
If documentation writers wanted to be more clear they could alway
discribe a container better than just *the container*.
They could say *the containing part* or *the containing document*

Editor:  A special type of part that can edit data.  A part that can
not edit data is called a viewer.  Note that an editor can be a
container.

===============================================================================
There is one thing that you said that I think is incorrect.

"Documents are called parts"

If it looked to you that some documentation said that, its because the
documentation was incorrect or you did not understand what it was saying
because it was unclear.

A document is not a part.  A document can contain a single part but a
document can not be a part.  You can also put one document into another
document, in which case one document is *part* of another document.

But you can't say Document A is *OpenDoc Part* of document B.  This
would not make sence.  So its unfortunate that the word part now
has two meanings and you have to read what a documentation writer
is saying in context.

Hope that this helps.

Eric Jackson
[e-mail]


---------------------------

>From [e-mail] (Nick Porcino)
Subject: Palettes and QuickTime
Date: 21 Nov 1995 20:32:46 GMT
Organization: Planet IX


Hi all, I'm having a major problem with Palettes and QuickTime.
I'm porting The Riddle of Master Lu from DOS to Mac, and am just about
done, except! I'm trying to use QuickTime to play back certain animations,
and I just can't seem to do it.

Because our art is already palettized, I have to initialize the palette
like this:

   // steal the device's color table
   CTabHandle gFade = (*(*hGD)->gdPMap)->pmTable;
   HLock((Handle)gFade);
   gamePalette = NewPalette(256, gFade, pmAnimated+pmTolerant+pmExplicit,
0x0000);
   SetPalette(gameWindow->GetWindow(), gamePalette, TRUE);
   gr_pal_system_init(gFade);

Then, I set up the palette like this (once in every scene, as every scene
has a unique
palette).

void gr_pal_set_range(RGB8* pal, int first_color, int num_colors)
{
   int i, last_color;

   last_color = first_color + num_colors;

   for (i=first_color; i<last_color; i++)
   {
      (*gFadeCtab)->ctTable[i].rgb.red = (short)(pal[i].r)<<8; // 8 bit
color values
      (*gFadeCtab)->ctTable[i].rgb.green = (short)(pal[i].g)<<8;
      (*gFadeCtab)->ctTable[i].rgb.blue = (short)(pal[i].b)<<8;
   }
   AnimatePalette(gameWindow->GetWindow(), gFadeCtab, first_color,
first_color, num_colors);
}

This works fine, except when I try to play QuickTime movies - despite the fact
that the palette in the hardware and the color in the movie are 1:1 identical,
the movie gets dithered to black and white.

I can find nothing in the QuickTime API or documentation to help.

HELP!!!!!!

- Nick Porcino
Sanctuary Woods, Victoria
Lead Engine Guy

+++++++++++++++++++++++++++

>From [e-mail] (Juri Munkki)
Date: 23 Nov 1995 14:58:44 GMT
Organization: Helsinki University of Technology

In article <nporcino-2111951131510001@204.239.240.138> [e-mail] (Nick Porcino) writes:
>This works fine, except when I try to play QuickTime movies - despite the fact
>that the palette in the hardware and the color in the movie are 1:1 identical,
>the movie gets dithered to black and white.

You used AnimatePalette and animated palette entries. This effectively hides
the colors from QuickTime, since animated colors are reserved and can only
be used through palette manager calls.

--
Juri Munkki [e-mail]      In cyberspace everyone can hear you scream.
http://www.iki.fi/~jmunkki              Windsurfing: Faster than the wind.

+++++++++++++++++++++++++++

>From [e-mail] (Christoph Bergmann)
Date: Sun, 26 Nov 1995 11:43:55 +1000
Organization: University of Queensland

In article <nporcino-2111951131510001@204.239.240.138>,
[e-mail] (Nick Porcino) wrote:

<snip>

> This works fine, except when I try to play QuickTime movies - despite the fact
> that the palette in the hardware and the color in the movie are 1:1 identical,
> the movie gets dithered to black and white.
>
> I can find nothing in the QuickTime API or documentation to help.
>
> HELP!!!!!!

try setting ctseed for the movie to = ctseed for the window.
this will fool quickdraw into thinking they are direct clones (even if
they were different)

hope this helps,
ChrisB

+++++++++++++++++++++++++++

>From [e-mail] (David Lawrence)
Date: Wed, 29 Nov 1995 07:44:08 GMT
Organization: NETCOM On-line Communication Services (408 261-4700 guest)

In article <nporcino-2111951131510001@204.239.240.138>,
[e-mail] (Nick Porcino) wrote:

> Hi all, I'm having a major problem with Palettes and QuickTime.
> I'm porting The Riddle of Master Lu from DOS to Mac, and am just about
> done, except! I'm trying to use QuickTime to play back certain animations,
> and I just can't seem to do it.



If you must use an animating palette, you can play a movie into a GWorld,
then copy each frame of the movie to the window.  We did this in
Warcraft's intro movies so we could fade a movie out while it was
playing.  I'm not looking at the code right now, but I think I remember
how I did it.  Here it goes:

Create a GWorld with the same color table that you are using elsewhere.
But you must set bit 14 of the color table's ctFlags field while
CopyBits'ing.  With this bit set, when you copy from the GWorld, the
colors are not remapped to the window's non-animated colors.  Always
leaving bit 14 set should be harmless.

Attach your animated palette to the GWorld with SetPalette (yes, this is
legal, with appropriate casting).  This ensures that QuickTime plays the
movie using the correct colors.  Set up the movie to play into the GWorld
(SetMovieGWorld I believe).  Set up a callback routine to CopyBits the
frames from the GWorld to the window after each frame is completed.  There
is sample code that uses these callback routines in the QuickTime sample
code at:

<http://www.info.apple.com/dev/devinfo/quicktime/dtsqtutils.html>


I think all this is correct.  If it doesn't work, let me know and I'll
look in the code to see exactly what I did before. (Good thing I commented
my code.)


By the way, I looked for a way to force a movie to play directly into a
window that is using animated colors, but with no luck.  If anyone knows
of a way, please let me know.


    David Lawrence
    Future Tense

---------------------------

>From [e-mail] (Nigel Stanger)
Subject: Passing a member function to DeviceLoop?
Date: Tue, 14 Nov 1995 12:15:04 +1300
Organization: Dept. of Information Science, University of Otago

Hi, here's an intersting problem. I'm converting a project from CW Object
Pascal to CW C++, and I've hit a slight snag with DeviceLoop routines. I
want to make my DeviceLoop routines member functions of a class, and set
up static UPPs to them so I can get at them. In other words, I ideally
want something like this:

NItem.h:

class NItem
{
  public:
      ...
    void Draw(); // this calls DeviceLoop
      ...
  private:
    static DeviceLoopDrawingUPP gPaintGray; // this will point to PaintGray()
    pascal void PaintGray(short, short, GDHandle, long);
};

(I'm going use CW's inherited:: extension, so it's OK for them to be
private, I think...) Now, in NItem.cp, I tried this:

...
DeviceLoopDrawingUPP NItem::gPaintGray =
NewDeviceLoopDrawingProc(&NItem::PaintGray);
...

Argh, boom, splat. I get a complaint about an illegal explicit conversion
from one function pointer type to another. Presumably this is because of
the implicit parameters that get passed to every member function. That's
what it looks like anyway (forgive if I'm speaking utter crap, I'm
relatively new to C++ :)

I tried using NewDeviceLoopDrawingProc(&NItem::PaintGray()) and got told
the definition didn't match the prototype. So I also tried
NewDeviceLoopDrawingProc(&NItem::PaintGray(short,short,GDHandle,long)),
which totally bamboozled the compiler :)

Has anyone successfully done this? Or is it impossible? I remember when I
first started writing this in THINK Pascal I hit a similar problem, but
couldn't get around it because you couldn't take the @ of a member
function :( The same thing obviously doesn't apply here, but coercing it
into something that both DeviceLoop and the compiler can understand seems
to be a non-trivial exercise.

=====================================================================
Nigel Stanger,           Internet: [e-mail]
University of Otago,     Phone: [phone]
Dunedin, NEW ZEALAND.    Fax:   [phone]

+++++++++++++++++++++++++++

>From [e-mail] (Francois Pottier)
Date: 14 Nov 1995 10:14:38 GMT
Organization: Ecole Normale Superieure, Paris

In article <[e-mail]>,
Nigel Stanger <[e-mail]> wrote:

>Argh, boom, splat. I get a complaint about an illegal explicit conversion
>from one function pointer type to another. Presumably this is because of
>the implicit parameters that get passed to every member function.

You're right. If you were allowed to use a member function, DeviceLoop
wouldn't know that it expects an additional parameter, so it would
call with wrong arguments and the world would end in a horrible crash.
So, the type-checker just saved your life :-)

>Has anyone successfully done this? Or is it impossible?

It's impossible to pass a member function to DeviceLoop. I can think of
several ways to get around this:

- Make your PaintGray function static, so that it doesn't require an
  implicit parameter, and use static private variables to pass data to
  it (very dirty).

- Alternatively, make PaintGray static and use DeviceLoop's userData
  parameter to pass data to it (slightly less dirty). That's what userData
  was invented for.

- Finally, a nice way is to not use DeviceLoop at all. If you have CodeWarrior,
  look at the StDeviceLoop class inside PowerPlant's code. It does the job for
  you and allows you to write all of your stuff in one place without any headaches.
  The only problem with this approach is that it bypasses DeviceLoop, so if
  Apple improves DeviceLoop, your code won't benefit from it. On the other hand,
  this approach works with non-color QD Macs, whereas DeviceLoop doesn't.

Hope this helps,

--
Francois
[e-mail]
http://www.eleves.ens.fr:8080/home/pottier/

+++++++++++++++++++++++++++

>From [e-mail] (Mike Cohen)
Date: Tue, 14 Nov 1995 18:57:29 GMT
Organization: ISIS International

In article <[e-mail]>,
[e-mail] (Nigel Stanger) wrote:

>Hi, here's an intersting problem. I'm converting a project from CW Object
>Pascal to CW C++, and I've hit a slight snag with DeviceLoop routines. I
>want to make my DeviceLoop routines member functions of a class, and set
>up static UPPs to them so I can get at them. In other words, I ideally
>want something like this:
>
[SNIP]
>
>Has anyone successfully done this? Or is it impossible? I remember when I
>first started writing this in THINK Pascal I hit a similar problem, but
>couldn't get around it because you couldn't take the @ of a member
>function :( The same thing obviously doesn't apply here, but coercing it
>into something that both DeviceLoop and the compiler can understand seems
>to be a non-trivial exercise.

You can't pass a non-static member function for ANY toolbox callbox
function. When a member function is called, it's passed a hidden "self"
argument, which won't work for toolbox callbacks. You can pass a static
member function, which can access any other static members, but doesn't
have a "self" instance defined.


--
Mike Cohen - [e-mail]
Home page: http://www.isis-intl.com/
Sound is the same for all the world - Youssou N'dour, "Eyes Open"

+++++++++++++++++++++++++++

>From [e-mail] (Scott Kevill)
Date: Thu, 16 Nov 1995 15:29:22 +0800
Organization: The University of Western Australia

In article <489q6e$[e-mail]>, [e-mail] (Francois
Pottier) wrote:

: In article <[e-mail]>,
: Nigel Stanger <[e-mail]> wrote:
:
: >Argh, boom, splat. I get a complaint about an illegal explicit conversion
: >from one function pointer type to another. Presumably this is because of
: >the implicit parameters that get passed to every member function.
:
: You're right. If you were allowed to use a member function, DeviceLoop
: wouldn't know that it expects an additional parameter, so it would
: call with wrong arguments and the world would end in a horrible crash.
: So, the type-checker just saved your life :-)
:
: >Has anyone successfully done this? Or is it impossible?
:
: It's impossible to pass a member function to DeviceLoop. I can think of
: several ways to get around this:
:
: - Make your PaintGray function static, so that it doesn't require an
:   implicit parameter, and use static private variables to pass data to
:   it (very dirty).
:
: - Alternatively, make PaintGray static and use DeviceLoop's userData
:   parameter to pass data to it (slightly less dirty). That's what userData
:   was invented for.
:
: - Finally, a nice way is to not use DeviceLoop at all. If you have
CodeWarrior,
:   look at the StDeviceLoop class inside PowerPlant's code. It does the job for
:   you and allows you to write all of your stuff in one place without any
headaches.
:   The only problem with this approach is that it bypasses DeviceLoop, so if
:   Apple improves DeviceLoop, your code won't benefit from it. On the
other hand,
:   this approach works with non-color QD Macs, whereas DeviceLoop doesn't.
:

I encountered this problem recently when I was adding multiple monitor
support for my Dialog Manager replacement code. I came up with a simple
and effective solution.

Each item had two methods Draw and DrawDepth.
    void DrawDepth(short depth, Boolean isGray);
    void Draw(void);

If an item needed to draw in colour it would do something like this:

void TDialogItem::DrawDepth(short depth, Boolean isGray)
{
   ......
}

void TDialogItem::Draw(void)
{
   DeviceLoop(itsDlog->macWindow->visRgn, DepthProc, (long) this, 0);
}

static pascal void DepthProc(short depth, short flags, GDHandle dev, long data)
{
    ((TDialogItem *) data)->DrawDepth(depth, !(flags & gdDevType));
}

There would just be one DepthProc that all the items would use.

Hope this helps,

Scott Kevill.
[e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (Jordan Zimmerman)
Date: Thu, 16 Nov 1995 09:19:25 -0900
Organization: Altura Software, Inc.

In article <[e-mail]>,
[e-mail] (Nigel Stanger) wrote:

> Hi, here's an intersting problem. I'm converting a project from CW Object
> Pascal to CW C++, and I've hit a slight snag with DeviceLoop routines. I
> want to make my DeviceLoop routines member functions of a class, and set
> up static UPPs to them so I can get at them. In other words, I ideally
> want something like this:
[snip]

You cannot pass a class member function pointer in place of a standard
function pointer. The way to do this is with a static member function that
is a wrapper around the class member function.

So:

class my_class
{
    ...
    void            my_member_func(void);
    static void     my_wrapper(void* user_ptr);
};

    ...
    SomeFuncThatTakesACallbackAndUserPtr(&my_class::my_wrapper, (void*)this);
    ...

void my_class::my_wrapper(void* user_ptr)
{
    my_class*   class_ptr = (my_class*)user_ptr;
    class_ptr->my_member_func();
};

--
Jordan Zimmerman, Altura Software
home page: http://www.altura.com/jordanz
Spock's Beard: http://www.altura.com/spocks_beard

+++++++++++++++++++++++++++

>From [e-mail] (Nigel Stanger)
Date: Fri, 17 Nov 1995 13:51:10 +1300
Organization: Dept. of Information Science, University of Otago

In article <ACCE34A99668B8ED4@10.0.2.15>, [e-mail] (Mike Cohen) wrote:
> You can't pass a non-static member function for ANY toolbox callbox
> function. When a member function is called, it's passed a hidden "self"
> argument, which won't work for toolbox callbacks.

I thought as much...

> You can pass a static
> member function, which can access any other static members, but doesn't
> have a "self" instance defined.

Aha, yes! That would do it. Making the routines static would actually also
make sense in this case too. I can see I still have quite a bit to learn
about C++ :)

Thanks! I'll try this out tonight.

=====================================================================
Nigel Stanger,           Internet: [e-mail]
University of Otago,     Phone: [phone]
Dunedin, NEW ZEALAND.    Fax:   [phone]

+++++++++++++++++++++++++++

>From [e-mail] (Martin-Gilles Lavoie)
Date: Fri, 17 Nov 1995 14:17:32 -0500
Organization: ZERCOM Technologies Inc.

In article <ACCE34A99668B8ED4@10.0.2.15>, [e-mail] (Mike Cohen) wrote:

> In article <[e-mail]>,
> [e-mail] (Nigel Stanger) wrote:
>
> >Hi, here's an intersting problem. I'm converting a project from CW Object
> >Pascal to CW C++, and I've hit a slight snag with DeviceLoop routines. I
> >want to make my DeviceLoop routines member functions of a class, and set
> >up static UPPs to them so I can get at them. In other words, I ideally
> >want something like this:
> >
> [SNIP]
> >
> >Has anyone successfully done this? Or is it impossible? I remember when I
> >first started writing this in THINK Pascal I hit a similar problem, but
> >couldn't get around it because you couldn't take the @ of a member
> >function :( The same thing obviously doesn't apply here, but coercing it
> >into something that both DeviceLoop and the compiler can understand seems
> >to be a non-trivial exercise.
>
> You can't pass a non-static member function for ANY toolbox callbox
> function. When a member function is called, it's passed a hidden "self"
> argument, which won't work for toolbox callbacks. You can pass a static
> member function, which can access any other static members, but doesn't
> have a "self" instance defined.
>

Better yet, declare a function declares as extern "C",, and make that
function call your desired method.  Sinple, and youstill get to use your
self ;-)

Martin-Gilles Lavoie
- -------------------------------------------------------------------
No!...try not.  Do, or do not.  There is no try.
    --Yoda on error handling.

Wars does not make one great.
    --Yoda on "Great Warrior"

+++++++++++++++++++++++++++

>From [e-mail] (Nigel Stanger)
Date: Wed, 29 Nov 1995 13:34:41 +1300
Organization: Dept. of Information Science, University of Otago

In article <[e-mail]>,
[e-mail] (Scott Kevill) wrote:
[...]
>
> If an item needed to draw in colour it would do something like this:
>
{...code snipped...]
>
> There would just be one DepthProc that all the items would use.

That's basically what I ended up doing, except I made my PaintGray routine
a static member function. In my Draw routine I coerce this to a long and
pass it to DeviceLoop in the userData parameter, then coerce it back
within PaintGray. Don't know if it works yet because I haven't finished
converting the rest of the code yet :)

Interestingly enough, that's exactly how I did it in the original Pascal
(except that PaintGray wasn't a member function), and it worked fine...

=====================================================================
Nigel Stanger,           Internet: [e-mail]
University of Otago,     Phone: [phone]
Dunedin, NEW ZEALAND.    Fax:   [phone]

---------------------------

>From [e-mail] (Thomas Haggie)
Subject: Question: Do you need to lock a Sound Handle before SndPlay
Date: 30 Nov 1995 15:52:00 GMT
Organization: Electronics and Computer Science, University of Southampton

I was wondering, I need to play sounds, do you need to lock a sound
handle before calling SndPlay with it? Also what happens if you call
release resource on the SndHandle before it has finnished playing?

                                        -*TOM*-

+++++++++++++++++++++++++++

>From "Andrew C. Plotkin" <[e-mail]>
Date: Thu, 30 Nov 1995 13:13:35 -0500
Organization: Carnegie Mellon, Pittsburgh, PA

[e-mail] (Thomas Haggie) writes:
> I was wondering, I need to play sounds, do you need to lock a sound
> handle before calling SndPlay with it?

Yes. Think about it: SndPlay takes a pointer, not a handle, so the
system has no way of calling HLock on it. And a pointer to the
contents of a handle can become invalid whenever memory is moved or
allocated. So if you leave it unlocked, there's a pretty good chance
that the sound will turn into a horrific screech halfway through.

> Also what happens if you call
> release resource on the SndHandle before it has finnished playing?

Same thing. Nothing will happen right away, because ReleaseResource
doesn't actually clear out the memory it releases. But the next time
you move memory, something new will be written into the memory that
the Sound Manager is reading, and you're back to the horrible screech.

--Z

"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the borogoves..."

+++++++++++++++++++++++++++

>From [e-mail] (Scott Kevill)
Date: Fri, 01 Dec 1995 14:33:02 +0800
Organization: The University of Western Australia

In article <[e-mail]>, "Andrew C. Plotkin"
<[e-mail]> wrote:

: [e-mail] (Thomas Haggie) writes:
: > I was wondering, I need to play sounds, do you need to lock a sound
: > handle before calling SndPlay with it?
:
: Yes. Think about it: SndPlay takes a pointer, not a handle, so the
: system has no way of calling HLock on it. And a pointer to the
: contents of a handle can become invalid whenever memory is moved or
: allocated. So if you leave it unlocked, there's a pretty good chance
: that the sound will turn into a horrific screech halfway through.
:

Sorry, SndPlay() *does* take a handle to the sound. It takes a pointer to
a sound channel. From what I've seen with other code, the handle doesn't
need to be locked, but it's probably a good idea to do it anyway.

: > Also what happens if you call
: > release resource on the SndHandle before it has finnished playing?
:
: Same thing. Nothing will happen right away, because ReleaseResource
: doesn't actually clear out the memory it releases. But the next time
: you move memory, something new will be written into the memory that
: the Sound Manager is reading, and you're back to the horrible screech.

SndPlay() itself moves memory so you could be in for problems. If you want
to release the resource after the sound has played, either play it
synchronously, then release it, or create a sound channel with
SndNewChannel() with a callback procedure. This procedure will be called
when the sound has finished playing, but you can't release the resource in
that procedure because it is called at interrupt time, so set a global
flag and keep checking that in the rest of your application. That's kind
of a long winded method, so there might be an easier way of doing it that
I can't think of at the moment.
:
: --Z
:
: "And Aholibamah bare Jeush, and Jaalam, and Korah: these were the
borogoves..."

Hope this helps,

Scott Kevill.
[e-mail]

+++++++++++++++++++++++++++

>From catambay#m#[e-mail] (Bill the Cat)
Date: 1 Dec 1995 15:22:26 GMT
Organization: MacPascal Mailing List

In article <[e-mail]>,
[e-mail] (Scott Kevill) wrote:

> In article <[e-mail]>, "Andrew C. Plotkin"
> <[e-mail]> wrote:
>
>
> : > Also what happens if you call
> : > release resource on the SndHandle before it has finnished playing?
> :
> : Same thing. Nothing will happen right away, because ReleaseResource
> : doesn't actually clear out the memory it releases. But the next time
> : you move memory, something new will be written into the memory that
> : the Sound Manager is reading, and you're back to the horrible screech.
>
> SndPlay() itself moves memory so you could be in for problems. If you want
> to release the resource after the sound has played, either play it
> synchronously, then release it, or create a sound channel with
> SndNewChannel() with a callback procedure. This procedure will be called
> when the sound has finished playing, but you can't release the resource in
> that procedure because it is called at interrupt time, so set a global
> flag and keep checking that in the rest of your application. That's kind
> of a long winded method, so there might be an easier way of doing it that
> I can't think of at the moment.

You can also skip the callback procedure, but still play it async and use
the sndchannelstatus function to query the channel to determine if the
sound has stop playing or not.  Doing it this way takes a bit more cpu
then using a global and a callback routine, but for simple situations, you
don't notice the difference.

_____________________________________________________________________
Bill Catambay
Pascal Programmer on Macintosh and Open VMS

              />
             //   The purpose of software engineering
     (//////[O]>=========================================-
             \\    is to manage complexity, not to create it.
              \>

____________________________________________________________________

+++++++++++++++++++++++++++

>From "Andrew C. Plotkin" <[e-mail]>
Date: Fri,  1 Dec 1995 11:50:35 -0500
Organization: Carnegie Mellon, Pittsburgh, PA

[e-mail] (Scott Kevill) writes:
> In article <[e-mail]>, "Andrew C. Plotkin"
> <[e-mail]> wrote:
>
> : Yes. Think about it: SndPlay takes a pointer, not a handle, so the
> : system has no way of calling HLock on it. And a pointer to the
> : contents of a handle can become invalid whenever memory is moved or
> : allocated. So if you leave it unlocked, there's a pretty good chance
> : that the sound will turn into a horrific screech halfway through.
>
> Sorry, SndPlay() *does* take a handle to the sound. It takes a pointer to
> a sound channel. From what I've seen with other code, the handle doesn't
> need to be locked, but it's probably a good idea to do it anyway.

Does it? Oh, look, it does. I wonder what the hell I was thinking.

Sorry.

Anyway, the point stands. Lock sounds before playing.

> If you want
> to release the resource after the sound has played, either play it
> synchronously, then release it, or create a sound channel with
> SndNewChannel() with a callback procedure. This procedure will be called
> when the sound has finished playing, but you can't release the resource in
> that procedure because it is called at interrupt time, so set a global
> flag and keep checking that in the rest of your application. That's kind
> of a long winded method, so there might be an easier way of doing it that
> I can't think of at the moment.

That's the only way I know of.

--Z

"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the borogoves..."

+++++++++++++++++++++++++++

>From [e-mail] (Jim Reekes)
Date: Fri, 01 Dec 1995 19:13:15 -0800
Organization: Apple Computer, Inc.

In article <[e-mail]>, "Andrew C. Plotkin"
<[e-mail]> wrote:

> [e-mail] (Thomas Haggie) writes:
> > I was wondering, I need to play sounds, do you need to lock a sound
> > handle before calling SndPlay with it?
>
> Yes. Think about it: SndPlay takes a pointer, not a handle, so the
> system has no way of calling HLock on it. And a pointer to the
> contents of a handle can become invalid whenever memory is moved or
> allocated. So if you leave it unlocked, there's a pretty good chance
> that the sound will turn into a horrific screech halfway through.

No. SndPlay() takes a handle. If you play it asynchronously then you need
to lock it. The function will lock for the duration of the function, but
restores its state before returning to the caller. So if you play it
synchronously you do not need to worry. It's only when play asynchronously
that it has to be lock by the caller.

--
Jim Reekes, Polterzeitgeist |       QuickTime Products R&D
                            |        Sound Manager Expert
Apple Computer, Inc.        | "All opinions expressed are mine, and
2 Infinite Loop  MS 302-3KS |  do not necessarily represent those
Cupertino, CA 95014         |  of my employer, Apple Computer Inc."

+++++++++++++++++++++++++++

>From [e-mail] (Jay Farrell)
Date: Fri, 01 Dec 1995 17:53:55 -0500
Organization: Jayfar's Web

In article <[e-mail]>,
[e-mail] (Scott Kevill) wrote:

| In article <[e-mail]>, "Andrew C. Plotkin"
| <[e-mail]> wrote:
|
| : [e-mail] (Thomas Haggie) writes:
| : > I was wondering, I need to play sounds, do you need to lock a sound
| : > handle before calling SndPlay with it?
| :
| : Yes. Think about it: SndPlay takes a pointer, not a handle, so the
| : system has no way of calling HLock on it. And a pointer to the
| : contents of a handle can become invalid whenever memory is moved or
| : allocated. So if you leave it unlocked, there's a pretty good chance
| : that the sound will turn into a horrific screech halfway through.
| :
|
| Sorry, SndPlay() *does* take a handle to the sound. It takes a pointer to
| a sound channel. From what I've seen with other code, the handle doesn't
| need to be locked, but it's probably a good idea to do it anyway.
|
| : > Also what happens if you call
| : > release resource on the SndHandle before it has finnished playing?
| :
| : Same thing. Nothing will happen right away, because ReleaseResource
| : doesn't actually clear out the memory it releases. But the next time
| : you move memory, something new will be written into the memory that
| : the Sound Manager is reading, and you're back to the horrible screech.
|
| SndPlay() itself moves memory so you could be in for problems. If you want
| to release the resource after the sound has played, either play it
| synchronously, then release it, or create a sound channel with
| SndNewChannel() with a callback procedure. This procedure will be called
| when the sound has finished playing, but you can't release the resource in
| that procedure because it is called at interrupt time, so set a global
| flag and keep checking that in the rest of your application. That's kind
| of a long winded method, so there might be an easier way of doing it that
| I can't think of at the moment.

Hmm.  I wonder if Apple's own Menu Clock is guilty of not doing this
correctly, perhaps not locking the handle or releasing the resource?  When
I set the clock to chime the hour/half-hour, if I use a sound of a few
seconds in duration the sound frequently breaks up screechingly part ways
through.  I've experienced this with System 7.5.1 (not sure about 7.5, as
I was using different clock s.w. then) with Sound Manager 3.0 & 3.1 on
both a Quadra 605 and on a Performa PPC 6115.

Cheers,
Jayfar

   ////~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~////
  ////   The Mops Page    <URL:http://www.netaxs.com/~jayfar/mops.html>    ////
 ////~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~////
////   Mops is Mike Hore's freeware Forth/Smalltalk hybrid for Macintosh ////
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  Jay Farrell     [e-mail]        Philadelphia, Pennsylvania, USA

---------------------------

>From [e-mail] (Ian Chan)
Subject: What's in a stack frame?
Date: Mon, 27 Nov 1995 12:20:10 GMT
Organization: Information Technology Institute

Hi,

  I'm learning to program on a Mac, and am writing a maze-generator/solver
program. Because I'm using recursion to do it, the space used by the stack
frames generated by each recursive function call adds up to a significant
portion of my memory use.

  Could anyone tell me what goes into a stack frame, so that I can try to
reduce the space it takes up? I'm using only 40bytes of locals vars and
parameters in each function, but watching the SP register increment after
each recursive call suggests that I'm using ~150bytes instead.

  I'm programming on a Powerbook 5300, if that helps, and the CW debugger
was on.

Thanks,
- Ian



+++++++++++++++++++++++++++

>From Edward de Jong <[e-mail]>
Date: 28 Nov 1995 20:59:14 GMT
Organization: magic mouse productions

Unfortunately the PowerPC code stack frame carries a lot of overhead
(much more than the 68k stack frame), so perhaps you should consider an
array, and not use a recursive solution.  Remember that recursion can
always be emulated with loops.



+++++++++++++++++++++++++++

>From [e-mail] (Reinder Verlinde)
Date: Mon, 04 Dec 1995 20:43:05 +0100
Organization: Rijksuniversiteit Utrecht

In article <49caek$[e-mail]>, [e-mail] wrote:

) Hi,
)
)   I'm learning to program on a Mac, and am writing a maze-generator/solver
) program. Because I'm using recursion to do it, the space used by the stack
) frames generated by each recursive function call adds up to a significant
) portion of my memory use.
)
)   Could anyone tell me what goes into a stack frame, so that I can try to
) reduce the space it takes up? I'm using only 40bytes of locals vars and
) parameters in each function, but watching the SP register increment after
) each recursive call suggests that I'm using ~150bytes instead.
)
)   I'm programming on a Powerbook 5300, if that helps, and the CW debugger
) was on.
)
The PowerMac runtime model eats stack for a living. I don't know the exact
details, but basically, the assumption is that half of the registers get
trashed in _any_  subroutine. Therefore, they are saved, not by the
callee, but by the caller. That probably are the ~150 bytes you loose.
Whether or not you actually need the local vars, you get them. There is
some reason for this. It is possibly related to pipelining, but it may
also be the observation that consecutive subroutine calls to 'leaf'
routines (i.e. routines which don't call other routines) would do extra
work if they were to save registers. The caller would not be so dumb to
restore, and then save registers. Anyway, for some reason the decision
was taken. Ask in the comp.powerpc.tech group for more info.
Disclaimer: I don't have a PowerMac (yet), so I'm not an expert.
The solution for your problem may be that you are better of writing the
program without recursion.

Reinder Verlinde

>From the index of Inside Macintosh:
   "Human interface Guidelines: see User interface Guidelines"
I wonder what they are aiming at. Monkeys? Aliens? Mice?

---------------------------

>From [e-mail] (Greg Chapman)
Subject: [Q] OpenTransport Introduction?
Date: Tue, 28 Nov 1995 16:25:12 -0500
Organization: U. of Western Ontario, OHS

Is there a good set of examples and/or documentation for programming
OpenTranport applications?

Cheers,

--
Greg Chapman - Mac Programmer/Developer
Systems Manager - U. of Western Ontario OHS
London, Ontario, Canada
email: [e-mail]
- -
"... cleans teeth, while you do dishes!"

+++++++++++++++++++++++++++

>From [e-mail] (Roger Smith)
Date: Tue, 28 Nov 1995 22:01:50 -0500
Organization: Gold Disk

In article <[e-mail]>, [e-mail] (Greg
Chapman) wrote:

> Is there a good set of examples and/or documentation for programming
> OpenTranport applications?
>
> Cheers,
>
> --

For a good example on OT programming, download the NewsWathcher source
code. It uses OT if available and MacTcp otherwise.

> The anonymous FTP site for the program, the user document, and the
> CodeWarrior C source code is:
>
>    ftp://ftp.acns.nwu.edu/pub/newswatcher/


The following URL's were taken from a recent MacTech  Magazine:

OpenTransport/TCP gopher://seeding.apple.com
                    ftp://seeding.apple.com/ess/public/mactcp/MacTCP_Dev_Kit
                     http://pilot.nijin.net/~msproul/

Roger

--
- -
Roger Smith
Gold Disk Inc.
Internet:[e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (John Norstad)
Date: Tue, 28 Nov 1995 22:21:31 -0600
Organization: Northwestern University

In article <[e-mail]>, [e-mail] (Greg
Chapman) wrote:

> Is there a good set of examples and/or documentation for programming
> OpenTranport applications?

Documentation:

    <ftp://seeding.apple.com/opentransport/OT_dev_info/>

One example, the source code for my NewsWatcher program:

    <ftp://ftp.acns.nwu.edu/pub/newswatcher/>

See the module "net.c", which contains all the Open Transport code.

--
John Norstad
Academic Technologies
Northwestern University
[e-mail]
<http://charlotte.acns.nwu.edu/jln/jln.html>

---------------------------

>From [e-mail] (Scott Dunbar)
Subject: [Q] Using Update Events
Date: Fri, 10 Nov 1995 19:44:04 -0800
Organization: BuggySoft Development

What's the correct or "standard" way of using handling an update event? I
tried to use the following code, but when it gets an update event in the
background it will draw the picture over any windows in the way which
causes quite a mess!
Here's my code:

updateEvt:
    begin
     BeginUpdate(WindowPtr(gEvent.message));
     if (WindowPtr(gEvent.message)) = gWindow then {make sure it's my window}
      CopyBits(offscreen^.portbits,
gWindow^.portbits,offscreen^.portRect,gWindow^.portRect, srcCopy, nil);
{copy the pict from my offscreen to my window}
     EndUpdate(WindowPtr(gEvent.message));
    end;

Thanks for any help at all!

- -
- Scott Dunbar
- BuggySoft™ Development
- [e-mail]
- IRC:  Poot
- http://users.aimnet.com/~buggysft/
- ftp://ftp.aimnet.com/pub/users/buggysft/

+++++++++++++++++++++++++++

>From [e-mail] (Ola Berg)
Date: 11 Nov 1995 22:06:43 GMT
Organization: Digit

Scott Dunbar,[e-mail],Internet wrote:

>What's the correct or "standard" way of using handling an update event?

If this is standard? I dunno. But it works fine! :-)

void HandleUpdate( WindowPtr win)
    {
    GrafPort old; // needed for restoring

    GetPort( &old); // saves the current grafport
    SetPort( win); // steers the drawing to the right win. This was your
probl.
    BeginUpdate( win); // tell EventMgr that the event is about to be handled
    MyDoDraw( win); // draws the contents
    EndUpdate( win); // Aah, updating ready!
    SetPort( old); // steers drawing back to the appropriate grafport
    }

BLSU!

<ichtys><
Ola

+++++++++++++++++++++++++++

>From [e-mail] (Ingemar Ragnemalm)
Date: 13 Nov 1995 19:51:05 GMT
Organization: (none)

[e-mail] (Scott Dunbar) writes:

>What's the correct or "standard" way of using handling an update event? I
>tried to use the following code, but when it gets an update event in the
>background it will draw the picture over any windows in the way which
>causes quite a mess!

>updateEvt:
>    begin
>     BeginUpdate(WindowPtr(gEvent.message));
>     if (WindowPtr(gEvent.message)) = gWindow then {make sure it's my window}
>      CopyBits(offscreen^.portbits,
>gWindow^.portbits,offscreen^.portRect,gWindow^.portRect, srcCopy, nil);
>{copy the pict from my offscreen to my window}
>     EndUpdate(WindowPtr(gEvent.message));
>    end;

I would SetPort to gWindow before CopyBitsing. Otherwise it looks ok.

--
- -
Ingemar Ragnemalm, PhD
Image processing, Mac shareware games
E-mail address: [e-mail] or [e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (M. Wuttke)
Date: Mon, 13 Nov 1995 20:49:18 +0100
Organization: -

> What's the correct or "standard" way of using handling an update event? I
> tried to use the following code, but when it gets an update event in the
> background it will draw the picture over any windows in the way which
> causes quite a mess!
> Here's my code:
>
> updateEvt:
>     begin
>      BeginUpdate(WindowPtr(gEvent.message));
>      if (WindowPtr(gEvent.message)) = gWindow then {make sure it's my window}
>       CopyBits(offscreen^.portbits,
> gWindow^.portbits,offscreen^.portRect,gWindow^.portRect, srcCopy, nil);
> {copy the pict from my offscreen to my window}
>      EndUpdate(WindowPtr(gEvent.message));
>     end;

Try calling

SetPort(WindowPtr(gEvent.message));

before drawing to the window.

Matthias

.....................................................................
Manfred & Matthias Wuttke             E-Mail: [e-mail]
Hilterweg 14                          Phone:  [phone]
D-33803 Steinhagen
Germany
:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::

+++++++++++++++++++++++++++

>From z044304 (James Derrick)
Date: Tue, 14 Nov 1995 07:30:13 +0800
Organization: The Chinese University of Hong Kong

In article <[e-mail]>,
[e-mail] (Scott Dunbar) wrote:

> What's the correct or "standard" way of using handling an update event? I
> tried to use the following code, but when it gets an update event in the
> background it will draw the picture over any windows in the way which
> causes quite a mess!

[ code snipped to pacify mailer]


You need to call SetPort, or SetGWorld before you do the CopyBits.

--
James Derrick

+++++++++++++++++++++++++++

>From [e-mail] (Richard Moyer)
Date: Tue, 14 Nov 1995 14:53:07 -0800
Organization: TRW

In article <[e-mail]>,
[e-mail] (Scott Dunbar) wrote:

> What's the correct or "standard" way of using handling an update event? I
> tried to use the following code, but when it gets an update event in the
> background it will draw the picture over any windows in the way which
> causes quite a mess!
> Here's my code:
>
> updateEvt:
>     begin
>      BeginUpdate(WindowPtr(gEvent.message));
>      if (WindowPtr(gEvent.message)) = gWindow then {make sure it's my window}
>       CopyBits(offscreen^.portbits,
> gWindow^.portbits,offscreen^.portRect,gWindow^.portRect, srcCopy, nil);
> {copy the pict from my offscreen to my window}
>      EndUpdate(WindowPtr(gEvent.message));
>     end;
>
> Thanks for any help at all!
>
Even though the event is in your window, that doesn't mean your window is
the current port. SetPort to gWindow and try again.

--
Dick Moyer, TRW
[phone]

+++++++++++++++++++++++++++

>From <[e-mail]>
Date: 15 Nov 1995 07:57:21 GMT
Organization: World-Net information exchange, Internet provider.

> updateEvt:
>     begin
>      BeginUpdate(WindowPtr(gEvent.message));
>      if (WindowPtr(gEvent.message)) = gWindow then {make sure it's my window}
>       CopyBits(offscreen^.portbits,
> gWindow^.portbits,offscreen^.portRect,gWindow^.portRect, srcCopy, nil);
> {copy the pict from my offscreen to my window}
>      EndUpdate(WindowPtr(gEvent.message));
>     end;

Try this :
                BEGIN
                        Getport(oldPort);
                        BeginUpdate();
                        SetPort(gWindow);
                        ......
                        EndUpdate();
                        SetPort(oldPort);


Have fun !



+++++++++++++++++++++++++++

>From [e-mail] (Christiaan Lutzer)
Date: Thu, 23 Nov 1995 19:15:05 -0700
Organization: University of Alberta

In article <[e-mail]>,
[e-mail] (Scott Dunbar) wrote:

> What's the correct or "standard" way of using handling an update event? I
> tried to use the following code, but when it gets an update event in the
> background it will draw the picture over any windows in the way which
> causes quite a mess!
> Here's my code:
>
> updateEvt:
>     begin
>      BeginUpdate(WindowPtr(gEvent.message));
>      if (WindowPtr(gEvent.message)) = gWindow then {make sure it's my window}
>       CopyBits(offscreen^.portbits,
> gWindow^.portbits,offscreen^.portRect,gWindow^.portRect, srcCopy, nil);
> {copy the pict from my offscreen to my window}
>      EndUpdate(WindowPtr(gEvent.message));
>     end;
>
> Thanks for any help at all!
>
> ---
> - Scott Dunbar
> - BuggySoft™ Development
> - [e-mail]
> - IRC:  Poot
> - http://users.aimnet.com/~buggysft/
> - ftp://ftp.aimnet.com/pub/users/buggysft/

You might want to try clipping the drawing region of your windows grafPort
to the "visRgn" using SetClip(gWindow^.visRgn); This will allow drawing in
only the visible region of the current grafPort. (which you will most
likely have set to gWindow)

Hope that works.  Later

+++++++++++++++++++++++++++

>From [e-mail] (Cameron Esfahani)
Date: Thu, 23 Nov 1995 19:09:17 -0800
Organization: Apple Computer, Inc.

Actually, just doing:
   updateEvt:
      begin
         BeginUpdate(WindowPtr(gEvent.message));
            if (WindowPtr(gEvent.message)) = gWindow then
               begin
                  GetPort(oldPort);
                  SetPort(GrafPtr(gEvent.message));
                  CopyBits(offscreen^.portBits,
gWindow^.portBits,                  offscreen^.portRect,
gWindow^.portRect, srcCopy, nil);
                  SetPort(oldPort);
              end;
          EndUpdate(WindowPtr(gEvent.message));
      end;

By doing the SetPort, Quickdraw will use the current ports clip/vis rgns
in doing the calculation of exactly what area of your window can be
overwritten.  It is also always a good habit to get into to save and
restore the current port whenever you change it.

Hope this helps you out,
Cameron Esfahani


In article <[e-mail]>,
[e-mail] (Christiaan Lutzer) wrote:

> In article <[e-mail]>,
> [e-mail] (Scott Dunbar) wrote:
>
> > What's the correct or "standard" way of using handling an update event? I
> > tried to use the following code, but when it gets an update event in the
> > background it will draw the picture over any windows in the way which
> > causes quite a mess!
> > Here's my code:
> >
> > updateEvt:
> >     begin
> >      BeginUpdate(WindowPtr(gEvent.message));
> >      if (WindowPtr(gEvent.message)) = gWindow then {make sure it's my
window}
> >       CopyBits(offscreen^.portbits,
> > gWindow^.portbits,offscreen^.portRect,gWindow^.portRect, srcCopy, nil);
> > {copy the pict from my offscreen to my window}
> >      EndUpdate(WindowPtr(gEvent.message));
> >     end;
> >
> > Thanks for any help at all!
> >
> > ---
> > - Scott Dunbar
> > - BuggySoft™ Development
> > - [e-mail]
> > - IRC:  Poot
> > - http://users.aimnet.com/~buggysft/
> > - ftp://ftp.aimnet.com/pub/users/buggysft/
>
> You might want to try clipping the drawing region of your windows grafPort
> to the "visRgn" using SetClip(gWindow^.visRgn); This will allow drawing in
> only the visible region of the current grafPort. (which you will most
> likely have set to gWindow)
>
> Hope that works.  Later

+++++++++++++++++++++++++++

>From [e-mail] (Tim Dierks)
Date: Sat, 25 Nov 1995 17:56:44 -0800
Organization: Stinky Cheese Man Fan Club

In article <[e-mail]>,
[e-mail] (Scott Dunbar) wrote:

> What's the correct or "standard" way of using handling an update event? I
> tried to use the following code, but when it gets an update event in the
> background it will draw the picture over any windows in the way which
> causes quite a mess!
> Here's my code:
>
> updateEvt:
>     begin
>      BeginUpdate(WindowPtr(gEvent.message));
>      if (WindowPtr(gEvent.message)) = gWindow then {make sure it's my window}
>       CopyBits(offscreen^.portbits,
> gWindow^.portbits,offscreen^.portRect,gWindow^.portRect, srcCopy, nil);
> {copy the pict from my offscreen to my window}
>      EndUpdate(WindowPtr(gEvent.message));
>     end;
>
> Thanks for any help at all!

Call SetPort(gWindow); to set the drawing port to your window so QuickDraw
will do all the appropriate clipping.

Best,
 - Tim

--
Tim Dierks - Software Haruspex - [e-mail]
If you can't lick 'em, stick 'em on with a big piece of tape. - Negativland

+++++++++++++++++++++++++++

>From Bridget Hardcastle <[e-mail]>
Date: 28 Nov 1995 14:44:24 GMT
Organization: Imperial College (EEE)

Aha! The bits of code that

>[e-mail] (Scott Dunbar) wrote:

i.e.

>> updateEvt:
>>     begin
>>      BeginUpdate(WindowPtr(gEvent.message));
>>      if (WindowPtr(gEvent.message)) = gWindow then {make sure it's my window}
>>       CopyBits(offscreen^.portbits,
>> gWindow^.portbits,offscreen^.portRect,gWindow^.portRect, srcCopy, nil);
>> {copy the pict from my offscreen to my window}
>>      EndUpdate(WindowPtr(gEvent.message));
>>     end;

look like the sort of thing I've been looking for for days!

My situation is that I'm obliged to write a program using a package that calls
itself Turbo 1.1, on a Macintosh SE/30. I'm learning Pascal from scratch
and the only manuals at college are for Pascal on an IBM PC.

My problem is that I cannot find the commands I need to use to put text (etc)
windows on the Mac; where can I find them? Are they listed somewhere
electronically? Do I have to look for a secondhand manual somewhere? I've
already checked out the college library.

Apologies for the amateurishness of this post; I'm trying...
Any help gratefully received, posted or emailed.

Bridget Hardcastle


+++++++++++++++++++++++++++

>From catambay#m#[e-mail] (Bill the Cat)
Date: 30 Nov 1995 16:04:12 GMT
Organization: MacPascal Mailing List

In article <49f788$[e-mail]>, Bridget Hardcastle
<[e-mail]> wrote:

>
> My problem is that I cannot find the commands I need to use to put text (etc)
> windows on the Mac; where can I find them? Are they listed somewhere
> electronically? Do I have to look for a secondhand manual somewhere? I've
> already checked out the college library.
>

For basic window handling, check out Inside Mac: Toolbox Essentials.  You
can get a free copy of it online at the following ftp site:

ftp://ftp.info.apple.com/Apple.Support.Area/Developer_Services/
    Technical_Documentation/Inside_Macintosh/

Good luck!

_____________________________________________________________________
Bill Catambay
Pascal Programmer on Macintosh and Open VMS

              />
             //   The purpose of software engineering
     (//////[O]>=========================================-
             \\    is to manage complexity, not to create it.
              \>

____________________________________________________________________


---------------------------

End of C.S.M.P. Digest
**********************